alias = compile-time variants?

Lutger lutger.blijdestijn at gmail.com
Sat Jul 31 12:17:06 PDT 2010


Jason Spencer wrote:

> == Quote from Philippe Sigaud (philippe.sigaud at gmail.com)'s article
>> --0016e6d58a039d35e2048c9aa7e2
>>
>> I thought they could only be symbols. That is, an alias is a 'link',
> a sort
>> of pointer to a symbol: a template name, a module name, a function
>> name, etc.
> 
> Whatever confidence you inspired by removing type from the list is
> quickly lost and more when you add module name--I hadn't thought of
> that! :)
> 
> 
>> Wisdom, I don't know, as I still feel like I'm exploring things. But
>> template constraints are there to limit what you can instantiate.
>> ...
>> Say I have a template that takes an alias, fun, and a type, T.
>> fun is supposed to be a function, but in fact why limit it to that?
>> What I need is for foo to be callable with a T. So let's test for
>> that:
>> auto doSomething(alias fun, T)(T t)
>> if (is(typeof( fun(T.init) )))
>> {
>> // now that I'm here, I can freely use fun as a callable on any T
>>  auto result = fun(t);
>> // ...
>> }
> 
> I understand this example, and (most of) the mechanics of constraints.
> What I'm not so sure about is the recommended practice around their
> use.  I see lot's of code that doesn't check those things.  Suppose
> you left off the constraint and did:
> 
> class Foo(U){}
> doSomething!(Foo, int)(3)
> 
> it seems like there's a good chance you could get:
> 
> auto result = Foo!(int);  // type inferred from 3
> 
> (since this doesn't actually work like I'm saying, please conveniently
> imagine a similar case that does. :)

Sure, but that would be quite a gotcha since you went from calling something to 
merely instantiating a template. Perhaps there are such gotcha's, I am not aware 
of them. 
 
> Even with your constraint, I'm not sure I feel any more comfortable.
> If it compiles in the body of doSomething, it will compile in the
> constraint--not sure I've added any value.

Perhaps not in this case, but:
- constraints add documentation, such as isInputRange!T or IsCallable!fun
- you can add a constraint that may not be statically checked inside the body of 
the template. This way you can still reject template parameters considered to be 
invalid even if the template body *could* be instantiated with them.
- a constraint is a nice place to add better compiler error messages
 
> So how do you sleep at night not knowing if there's some funky syntax
> on somebody's template-that-takes-a-template which, when combined with
> some inference, might look like your function call on a value param?
> My initial reaction is to specify the hell out of the constraints, but
> I couldn't beat the feeling I was going overboard.  I suspect that
> most people rely on the fact that most improper calls won't compile.
> Maybe I'm still too new to the syntax to have a good feel for what
> will get caught, and what could interpreted by the compiler in
> multiple ways depending on the actual arguments.
> 
> So, do folks write constraints to ensure that modules don't get passed
> to their templates?  :)
> 
> Jason

Why not? As long as your module does the right thing, it may be used to 
instantiate my template :)


More information about the Digitalmars-d-learn mailing list