Cleaner syntax for generics

In some traditional programming languages, the "!" symbol is (surprisingly) underutilized as: v1) postfix operator; v2) binary operator.

The above insight is the driving force for D's template syntax (see OP). It is already valuable that this is considered up to this point.

Furtherly, current situation is: v1) marks macros in Rust v2) is somewhat still available in Rust (the proposal is mainly oriented towards this one).

Syntax is subjective, but generally "<>", "::" and "::<>" (the turbofish, a cute name but the syntax less so...) are quite eyeball-scratching. An "!"-based alternative to these is the core suggestion.

Some links about the "<>", "::" and "::<>" syntax: l1) https://www.reddit.com/r/programming/comments/108j8um/comment/j3t4zzi/?utm_source=share&utm_medium=web2x&context=3 (original post is deleted, but the quote remains) l2) https://www.reddit.com/r/rust/comments/v4rir6/turbofish_why/

You're right about syntax being subjective. For instance, the Option!Rc!RefCell!Node example really grates on me. It looks less readable than what we have today.

Rant

Option!(Rc!(RefCell!(Node))) is an improvement over the shorter form, but it's objectively worse than Option<Rc<RefCell<Node>>> because it has extra characters that provide no value, and the angle brackets are just replaced with parentheses.

The example code in the OP is unformatted, so it took a non-negligible amount of time to parse it. But I still have trouble seeing how the proposal improves anything.

It replaces SingleGen<T>(T) with SingleGen!(T)(T) which has the same issue as above. The struct SingleGen(T) form is ambiguous [1] so you are left with the longer, less ambiguous form.

While syntax matters (and there are some good arguments in this thread already for changing syntax in at least some cases) remember that if it's eyeball-scratching enough, you could always create your own DSL with macros or (ugh) a C-like preprocessor. This has some obvious benefits such as (if you're okay with using a DSL) being able to use the syntax directly in your projects, and secondly gaining some real-world experience with the syntax in practice. That latter point is going to be far more useful than imagining what it might be like to use the syntax.


  1. Is T supposed to be a generic type, or is it a concrete type named T? Compare with struct Single(A); same question for A in this case. ↩︎

4 Likes

I disagree the macro and generics are related.

If you want that kind of syntax you will need another character for generics or you will need to change the macro invocation. For instance Option`Rc`RefCell`Node would seem pretty clean to me, far less heavy than exclamation point or brackets, while I don't think the issue is important enough to introduce a new syntax at this point.

I did that kind of thing long ago too, while my incontrovertibly correct opinion does not exactly match yours :wink:

2 Likes

Suddenly, I’m feeling strong Unlambda vibes…

Just to emphasize how subjective this can get, I don't like this syntax for the same reason I have never liked 'a for lifetimes: unpaired quotation marks.

A more practical objection is: with this or any other syntax that doesn't involve some kind of balanced delimiter, nested type parameters become ambiguous the moment something in the chain takes more than one type argument. (Concretely: How exactly do you translate Result<Vec<u32, PoolAllocator>, io::Error> to this syntax, and how would you know that the type wasn't meant to be Result<Vec<u32, PoolAllocator, io::Error>> or Result<Vec<u32>, PoolAllocator, io::Error>?)

Always a problem with this sort of thing. (I don't consider symbol overloading to be a serious problem, and I actively want the return type outside the function call parentheses; on the other hand, I quite like [] for type parameters -- but my rationale would include "square brackets are under-utilized by being reserved for array indexing".)

1 Like

I always liked the haskell (ocaml?) approach of mere juxtaposition, Option (Rc (RefCell Node)), which let's you drop a level of grouping and all commas. I don't think it could have fit into the rest of Rust's syntactic style at all though.

2 Likes

Respectfully, is there any reason whatsoever for continuing this discussion? I'm pretty sure we can all agree that there is absolutely zero chance of the existing syntax changing, even over an edition.

17 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.