Struct-typing in Phobos

[Jakob Ovrum]

On Tuesday, 4 February 2014 at 02:04:55 UTC, Chris Williams wrote:
> And of course, even being able to read it, one would still need 
> to track down isInputRange() and isImplicitlyConvertible() to 
> know what they do.

Having to know what a particular concept does is pretty much the 
same as having to know what an interface does. Even so, 
`isImplicitlyConvertible` should be intuitive to programmers with 
some experience in any statically typed language.

> 2. When using classes and interfaces, type checking is as 
> simple as writing the type to be passed in as a parameter. With 
> struct-typing, people need to manually append a series of 
> checks all over the place, which results in things like the 
> following:
>
> auto uniform(T, UniformRandomNumberGenerator)(ref 
> UniformRandomNumberGenerator urng) if (!is(T == enum) && 
> (isIntegral!T || isSomeChar!T));
>
> Even though isUniformRNG() exists and is used on other 
> implementations of uniform(), it isn't used here, because 
> whoever developed the function forgot to include it on this 
> particular function.

Repeatedly needing to check for something nameless yet specific 
like what the above does, is probably cause for introducing a new 
concept.

I'll admit that getting constraints right is difficult, because 
it's impossible to unit test whether an error happened because of 
an immediate resolution failure or something else. We need some 
improvement here if we want to keep aiming for tight constraints.

> 3. Non-extensible. To "extend" an SList or whatever, I would 
> have to write a wrapper class with methods that forward to the 
> SList methods, if I wanted my object to be able to interoperate 
> with Phobos, or I would need to modify Phobos so that the body 
> of SList was a template that could be mixed in (assuming I 
> didn't want to override any methods, just add new ones).

Use UFCS to add new methods.