I have been fiddling with Options in Nim.
some(now()) and none(DateTime) look syntactically similar but work fundamentally differently:
The similar form func(...) hides that one takes a value, the other a type.
Proposal: Make the syntax reflect the semantics:
none[] visually looks like an empty box, which matches what it does.
Thoughts?
This breaks the language consistency. none and some are function calls and they work fundamentally in the same way.
If you suggest they remain as such, then they also must allow none[]() and none() forms. Which means they take no arguments (or a default) and the former is a generic. But a generic can't take nothing, there should at least be something like auto inside [].
The other option (speaking syntactically, makes no sense otherwise) is making none and object, but then [] becomes a function call, which is conventionally used for dereferencing, which would be confusing in this case, or element access, which makes even less sense.
The only other option is making none a keyword, which could work, but that would require making Option a part of the language, not just the standard library, and this won't happen anytime soon.
---
Tangentially, Nim allows both to[TypeDesc] and to(TypeDesc) call forms and, for example, in my itertools PR I had an option to choose one or the other forms (or both) for the collect operation, but I've chosen collect(TypeDesc) just to follow the conventions, even though the latter form conceptually allows the excessive .collect[Foo](Foo) usage (haven't check if compiler is happy with it, though).
As usual, conflating Result and Option.
Case in point regarding the keyword addition possibility ;)