Fantom currently makes an exception for Lists and Maps, allowing the constructors and types to be parametrized.

This does not extend to users being able to create similar parametrizable types, for reasons we can all agree: a trade-off between complexity and flexibility.

I know some will feel the loss of power is regrettable, but I don't want to revisit that argument, which has been well covered here.

I think that List and Map types should be treated consistently in the type system, and this does not now happen. I'm going to argue that the cost of doing this in type system complexity is very small.

Specifically I suggest that the methods map and reduce on List, and map on Map, propagate static type inference accurately within the current Fantom type system.

Note I am not asking for type inference to be done in a different way, or with a larger set of inferred types. I am not asking for user-defined types to have more complex signatures.

The only extension is that as a special case, just like List and Map themselves, the system defined map and reduce on List and Map have signatures that include a wild card, so that static types are inferred as expected across map and reduce.

The extra type protection coming from this change would be small but useful. The motivation is that inconsistent semantics in a language is annoying. Built-in List and Map have special parametrization syntax - it is consistent for their associated methods to have special type signatures so they work properly in a static type system.

The current semantics is unexpected. I think it is a small thing, but one that will aggravate new users of Fantom (it did me, because I just could not imagine that map, reduce would not give accurate static types for their results within the Fantom type system).

There is as far as I can see no leakage from this into the rest of the type system which stays simple. The motivation for map and reduce being special is that this is consistent with List and Map being special. User-defined wildcards in signatures are not needed just as user-defined parametrized types are not needed.

The (special) single wildcard type for map and reduce could never be written in Fantom code but would need to have a unique name for purposes of reflection.

I'd imagine it'd be difficult / complicated to implement, because to determine the returned type you'd need to look ahead in the code block to find (and evaluate) the return statement.

l := [1, 2].map { it.toStr }
echo(l.typeof.signature)  // --> sys::Obj?[]

l = [1, 2].map |v->Str| { return v.toStr }
echo(l.typeof.signature)  // --> sys::Str[]

But given it only needs to be applied to it-blocks, it may not be that bad.

I would find it useful though, I use the map methods a lot.

OK - you are right the static type checker currently tests closure return type against a known signature always.

There are a lot of old threads from 2009 about type inference on closures, but I can't find anything precisely to the point here.

There does not seem to me to be a lot of difference between what is needed here and what already done - but I may be wrong!

It's a shame that Xored F4 doesn't honour this type inference. Instead it gives me a compilation error:

l := [1, 2].map |v->Str| { return v.toStr }
echo(l.typeof.signature)  // --> sys::Str[]
		
l.first.lower  // --> Unknown slot 'sys::Obj.lower', D'Oh!

I'm forever forced to cast the list manually.

: (

The ability to infer the return type of map is definitely something that would be very valuable - that and lack of built-in Sets are my top issues with current type system. So I agree it would be nice. Yes it is localized to built-in types, so would avoid complexity associated with future user defined generics. But at the same time, it definitely is not a trivial change - it would be the first time the parameterized type system had to apply a method argument type to infer the return type. I've actually been giving some thought to that problem on and off lately.