I've received feedback that the two types of map type syntax are confusing. Fan currently has:

Key:Value
[Key:Value]

These are confusing because:

• there are two syntaxes for the same thing
• they don't look like the list syntax
• they don't mention map (as Java/C# do)

The first alternate direction:

Value[Key]

This is unambiguous, but has a certain sense of being backwards (which is strange, as it is logically correct)

The second alternate direction:

Map[Key,Value]

This has benefits of being instantly readable by Java/Scala/C# and being setup for the long term should Fan ever decide to extend the scope of generics. Obviously list would become List[Value].

Any opinions on this one? I tend to think that the second alternative is much more mainstream and gives Fan the ability to grow. It is more keystrokes, but not that many more (3-5).

I definitely do not want to start down a path of making the 3 built-in generics look like Java style generics because I don't want to boxed into a specific syntax if we ever decide to add user defined generics. For example I prefer Java's T<A> syntax to Scala square brackets.

The map type syntax is [Key:Value]. It is merely syntax sugar to omit the brackets when not needed. I am not sure why that is so confusing. Although now that we have added nullables, type signatures have gotten more complex. I might consider requiring the use of brackets - but then again there are ton of public APIs which use the simple syntax of Str:Str or Str:Obj.

The generic syntax for list, map, and functions is designed to mimic their use. In the case of maps, I think the current syntax is pretty darn consistent:

[Key:Val] map := [keyA:valA, keyB:valB ...]

The map type syntax looks exactly like the map literal syntax.

The map type syntax looks exactly like the map literal syntax.

I should point out that the list type syntax doesn't based on that measure:

Val[] list := [valA, valB, ...]

More consistent would be

[Val] list := [valA, valB, ...]

This isn't something I'm especially bothered by, but it is a worry that it received some negative feedback.

I agree it is not perfectly consistent, but it works because people associate lists with the array syntax from C like languages. So I think lists and function signatures work really well. And this is the only complaint I've heard about the map syntax. I don't love the map syntax as much as list and function, but I don't think it worth changing.

+1 for consistency with C/C++

As with human languages, precision and consistency is not as important as familiarity. At least for me any languages that is too alien from C makes me feel uncomfortable; it is good to play with, but if I were to implement a library on it I want to make sure that there are significant others that would find the language comfortable to work with as well.