Not everything is about usefulness, language consistency and coherence is as important, it allows you to predict what you can expect from a language, it allows you to abstract away different features into general mechanisms of the language. The more special cases there are, the more exceptions to a general rule, the harder it gets to keep those abstract concepts together and thus the harder it gets to fully comprehend a language. Sometimes that means rejecting a convenience since it would depend on too many more additions needed to make the big picture coherent again, to introduce the "abstract concept".

I agree with what you say, every new rule we add to the language could introduce additional complexity and make things not coherent.

The way I see it, we then have three options:

1. Leave things as they are
2. Make T? be equivalent to Union(T, Nil)
3. Remove the T? shortcut from the type grammar

So, T? is a special case in the type grammar, doing T | Nil is the same, so we could remove it.

However, the ? at the end of something already means "nilable". For example [] and []?, to_i and to_i?, first and first?, etc. Having T? mean nilable would be consistent, in my opinion.

Then, some other languages also use T? to mean nilable types: C#, Swift (they call it optional types, but the concept is equivalent), Flow (though they put it as a prefix) and probably many others. That means that people coming from other language will find the concept familiar.

And, if Crystal is their first language, or they are not familiar with nilable types, they will still see T? in libraries and code, because it's used a lot (451 occurrences in the crystal repository), and they'll see it in API docs.

Now, the use cases:

1. We could use it in JSON.mapping to pass Int32? instead of the more verbose Int32 | Nil
2. In crystal-pg you can pass Int32|Nil as an expected type, so you could pass Int32?.
3. In crystal-db we have read(T.class) and read?(T.class) methods to read non-nilable and nilable types from a database column. This is fine and works, but now let's write a method that reads an entire row, and you pass the expected types. You can't do that very easily. You'll have to call read? if the type is nilable (this check is kind of hard to do, it's not just using nil?) or read if the type is not nilable. It would be nice if one could pass T? or T to read and that's it. Then you can pass the types from the tuple directly. Of course one can use Union(T | Nil), but I don't see why we need the verbosity given that T? is available in another place in the language grammar.

A bit more of point 1. Check these codes, which one looks more consistent:

# 1
class Foo
  JSON.mapping({
    x: Int32,
    y: String | Nil,
  })

  property other : String?
end

# 2
class Foo
  JSON.mapping({
    x: Int32,
    y: String?,
  })

  property other : String?
end

If we don't introduce String? I can only imagine people asking "why I can't use String? here", not the other way around "Oh, this is not the type grammar".

Finally, making T? parse as Union(T, Nil) is not a breaking change, as it's unlikely that someone was using a type as a conditional in the ternary operator.

Anyway, I'll leave this PR floating here a bit more until we gather more opinion and evidence on this.

To clarify, the type grammar already has more special rules:

• T? for T|Nil
• T* for Pointer(T)
• T -> U for Proc(T, U)
• {T, U} for Tuple(T, U)
• {foo: T, bar: U} for NamedTuple(foo: T, bar: U)

The inconsistency would be to port one of these to the regular grammar, but the others. In fact porting the last two is probably impossible, they are already valid but mean different things.

You simply move the "Oh, it's not the type grammar" from T? to one of the others.

In common syntax, I agree T? would be useful - it's such an integral part of the type-system, and idiomatic coding in Crystal. And of course the other (T* for instance) should not be facilitated. Personally I think T* should probably be usable only in lib/c-interfacing if at all (and that's from someone who do a lot of evil pointer working)

I understand. However, I think nilable types are more useful and used in general, as opposed to pointers, tuples and named tuples. I can also imagine wanting to read a nilable int from a database, or from a JSON, but not a nilable tuple, as these types usually don't exist in databases, JSON, etc.

There's on more, proc types, like Int32 -> String. But again, you can't parse a proc from a database, JSON, etc. Basically, I can imagine types being passed to methods to read/deserialize stuff, and nilable types are common, while pointers and procs are not (tuples and named tuples might appear too, but I'd say that they are not as common as nilable types).

Merged in 40c6f73

(I know some were against this, but it has many use cases and it'll eventually be more clear)