Bill Baxter, el 16 de noviembre a las 15:42 me escribiste: > On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella <llu...@gmail.com> wrote: > > This topic is actually very close to a discussion last week about > retrieving error messages from failures of __traits(compiles, xxx). > > My question is: is it really that much of an improvement? > > I've rearranged your code to see the equivalent snippets side-by-side: > > > static interface InputRange(T) { > > bool empty(); > > T front(); > > void popFront(); > > } > > > > template isInputRange(R) > > { > > enum bool isInputRange = is(typeof( > > { > > R r; > > if (r.empty) {} > > r.popFront; > > auto h = r.front; > > }())); > > } > > There's actually not that much difference here. Of course we would > like several general improvements that have been discussed before: > 1) some kind of template 'this' so we don't have to repeat the template name. > 2) something better than is(typeof()) (or __traits(compiles, ...)) to > check if code is ok. [hoping for meta.compiles(...)] > > In some ways the current code is better, because it actually checks if > a construct works or not, rather than requiring a specific function > signature. Whether the code will work is really the minimal > restriction you can place on the interface. A specific may be too > tight. For instance, above you don't really care if empty returns > bool or not. Just if you can test it in an "if".
I think one could argue if being more restrictive is actually good or bad. Being more restrictive cold lead to less errors. Maybe if a struct empty() method returns, say, a pointer, I don't want to think it is *really* a range. Maybe that method is doing a lot of work and removing stuff, and then returning a pointer to some removed stuff. Anyway, I'm not saying that that couldn't happen even if empty() return bool (that's a risk when duck-typing, always :), I'm just saying I'm not so sure that being more restrictive is really a *bad thing*. And about what's nice or ugly, I agree the current way of doing stuff is not too bad, there are a few details that are not *that* nice. But with duck-typing I think the same that with tuples: those little details makes you feel that D doesn't support the concept so well, and make people resistant to use them. When something feels natural in a language, you use it all the time, for me, the current way to do tuples and duck-typing looks very artificial and harder than it should. > But in terms of functionality it seems we cover pretty much everything > static interface gives you. I know that, I started this proposal just saying that =) Again, this proposal is about what I say in the previous paragraphs. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Be nice to nerds Chances are you'll end up working for one