On Thursday, 23 July 2015 at 14:15:30 UTC, Andrei Alexandrescu
wrote:
On 7/23/15 5:07 AM, Walter Bright wrote:
On 7/22/2015 11:47 PM, Jacob Carlborg wrote:
On 2015-07-22 20:47, simendsjo wrote:
Traits
------
I think the ability to express an interface without buying
into
inheritance is the right move. The alternative in D is
specifying the
behavior as a template
I completely agree and don't really like the approach D has
implemented template
constraints. Yeah I know, Andrei will destroy this :)
Consider that template constraints can be arbitrarily complex,
and can
even check behavior, not just a list of function signatures
ANDed
together. Turns out many constraints in Phobos are of the form
(A || B),
not just (A && B).
Agreed. And that's just scratching the surface.
It is definitely a big issue for designing more advanced generic
libraries and one of my major issues with Rust but you need to
realize that vast majority of application domain usage of such
constraints is simply ensuring list of methods. You may be biased
by too much standard library development ;)
At the same time one HUGE deal breaker with rust traits that
rarely gets mentioned is the fact that they are both constraints
and interfaces at the same time:
// this is template constraint, it will generate new `foo` symbol
for each new T
fn foo <T : InputRange> (range : T)
// this use the very same trait definition but creates "fat
pointer" on demand with simplistic dispatch table
fn foo (range : InputRange)
It kills all the necessity for hacks like RangeObject and is
quite a salvation once you get to defining dynamic shared
libraries with stable ABI.
This is probably my most loved feature of Rust.
Serious question: how do you express in Rust that a type
implements one trait or another, then figure out statically
which?
As far as I understand current idiomatics, you don't. Code that
tries to use functions that are not ensured by trait will simply
not compile and for any complicated generic programming one is
supposed to use macros. Rust does not have templates, only
trait-restricted generics.
I find it terribly unproductive but it seems to appeal to certain
developer mindset, primarily the ones that associate "templates"
with "C++ templates".
