Rant after trying Rust a bit

[Walter Bright via Digitalmars-d]

On 7/24/2015 4:55 AM, Artur Skawina via Digitalmars-d wrote:
> Basically, it can work like this:
>
> - traits, like your 'hasPrefix', check that 'T' implements an
>    interface (defined in hasPrefix).
>    (this does the job that template constraints do right now, and
>    more [1])
>
> - the compiler instantiates the template with a mock (defined
>    inside 'hasPrefix').
>    (this immediately catches every illegal access, like 't.suffix'
>    and results in a clear and informative error message)

That really isn't any different from a user calling it with a 'hasPrefix' that 
doesn't have a 'suffix'.


> - the 'T' inside foo is still the original type that it was called
>    with, so 'bar(t)' will succeed. But it needs to be conditionally
>    enabled for just the types that implement 'hasColor' -- and this
>    is exactly what you'd want from traits. So guard it, for example,
>    `static if (is(T:hasColor)) bar(t);`; note that when 'bar(t)` is
>    an alias or mixin, this can be done inside the aliased or mixed-in
>    code.

As I mentioned in the antecedent, this pulls the teeth of the point of the 
trait, because what the function needs is 'hasPrefix && hasSuffix', and your 
position is that only 'hasPrefix' is required. This leaves us exactly where D is 
now.


>    There are some syntax sugar possibilities here (aot there should
>    be a way to access other traits without introducing a named function).
>    http://forum.dlang.org/post/mailman.4484.1434139778.7663.digitalmars-d@puremagic.com
>    has one example, using a slightly different syntax (the 'idiomatic D'
>    way would be an is-expression inside static-if introducing the alias,
>    but `is()` makes code extremely ugly and unreadable).

As I mentioned to Dicebot, syntactical improvements are possible (though I don't 
think we should rush into things here).


> [1] "and more": it allows for overloading on traits, something
>      that can not be (cleanly) done with constraints.

Overloading with constraints is commonplace in Phobos. Haven't really had any 
trouble with it.


>> Now consider a deeply nested chain of function calls like this. At the bottom, one adds a call to 'color', and now every function in the chain has to add 'hasColor' even though it has nothing to do with the logic in that function.
> No, as long as the extra functionality is optional no changes
> to callers are required, at least not for statically dispatched
> code that we're talking about here.

That's how D works today.