i like the idea of letting a type do double duty as a variable name if it's obvious in context, and being aliased by an explicit name if wanted/needed, but letting the order be irrelevant sounds like unnecessary flexibility to me - it makes writing no easier, and reading harder.
This is covered in the FAQ. Partly, I allow it because there are no parsing ambiguities with it, so why not. But moreover, depending on type name & variable names, intelligently beginning or ending with an alias can lead to extremely fluent APIs. "that(expected Bool)Equals(actual Bool)" vs "writeTo(Linkable output)". This freedom can lead to more readable APIs in any language, not just English.
Of course, I do see where the complaints come from, and a part of me fears the day that someone releases a wake linter which requires aliases to follow the type. If that were to happen I think I'd nix the idea in favor of unity in the community.
that's a good point, and the line of code does read fluently. i'd still argue that blurring the "alias = noun, type = adjective" metaphor is a bad idea; you couldn't write
that(expected Bool, expected Int)Equals(actual Bool, actual Int)
to match on two values, for instance. on the other hand, constraining the adjective to come before the noun is an english-based convention, so you're probably right about seeing which way the community leans before doing anything.
Comments
one very curious design decision is to allow type aliases either before or after the type. so, from the examples, you have
i like the idea of letting a type do double duty as a variable name if it's obvious in context, and being aliased by an explicit name if wanted/needed, but letting the order be irrelevant sounds like unnecessary flexibility to me - it makes writing no easier, and reading harder.
This is covered in the FAQ. Partly, I allow it because there are no parsing ambiguities with it, so why not. But moreover, depending on type name & variable names, intelligently beginning or ending with an alias can lead to extremely fluent APIs. "that(expected Bool)Equals(actual Bool)" vs "writeTo(Linkable output)". This freedom can lead to more readable APIs in any language, not just English.
Of course, I do see where the complaints come from, and a part of me fears the day that someone releases a wake linter which requires aliases to follow the type. If that were to happen I think I'd nix the idea in favor of unity in the community.
that's a good point, and the line of code does read fluently. i'd still argue that blurring the "alias = noun, type = adjective" metaphor is a bad idea; you couldn't write
that(expected Bool, expected Int)Equals(actual Bool, actual Int)
to match on two values, for instance. on the other hand, constraining the adjective to come before the noun is an english-based convention, so you're probably right about seeing which way the community leans before doing anything.
doesn't the same apply to $Type ? It seems like unnecessary extra syntax, I'd prefer a simple "if there is ambiguity, name the variables".