Do I understand correctly that this allows type variables of classes to have arbitrary names, but no change for methods?

@BlaXpirit Yes, this is for type variables of classes and modules, but what do you mean with no change to methods? I guess it means that we don't yet introduce either def (U) nor syntax for free variables, and that is correct.

def f(a : SomeType, b : SomeType)

It is possible to make any unexisting type become a type variable. This makes little sense, but looking at the title and with no evidence to the contrary, this pull request can be (mis)understood like this.

Yes, it can be confusing. But no, your example will give an error if you invoke that method and SomeType doesn't exist. For free variables unrelated to type variables you still have to use T, T1, etc.

We are going back and forth with this. I would say to first decide what to do about #3288

I consider this a better alternative to #3288. No ugly syntax is introduced and classes get to introduce long-lived class names, while methods can still easily get away with the short names just for that one method, and compensate with docs if absolutely necessary.

I think it adds to the confusion.

• single letter constant: generic or freevar.
• longer constants: type.

With this convention I can NEVER confuse a generic type from a type, but if the restriction is lifted, well, there will be NO way to distinguish them without going back to the class definition.

@ysbaddaden has a very valid point.

Perhaps the better solution is simply to promote an idiomatic Crystal de-facto naming scheme of using (completely arbitrarily chosen suggestions here): class Foo(X, Y, Z) for type parametrizations, and def foo(x: T -> U, y: V) for method typevars - just to avoid accidental non intended effects. Or add one of the methods of specifying it explicitly when wanted as per #3288.

Or! Even enforce a naming scheme separating type-level and method-level generic symbols! However to do that cleanly, the only way is probably partitioning the letters as in above example - which might be a bit too extreme.

On the other hand, with this long-names-allowed syntax, a idiomatic naming convention will also solve the problem, with less restrictions. class Foo(ElementT, SomeOtherT), def foo(x: T -> U, y: V). That's probably the cleanest way to go about it.

I've grown very fond of the "duck-lexing" concept prevalent in Crystal. It makes it very easy for a human being to immediately grasp what the intentions and roles of a piece of code and it's identifiers means.

Limitations imposed in that regard are good constraints imo (increases clarity of intent).

@ozra Can you expand on what you mean by "duck-lexing"?

@RX14 "if it looks like a duck, it probably is a..." B-)