The Thermopylae excerpt of TDPL available online

[Lars T. Kyllingstad]

Don wrote:
> Lars T. Kyllingstad wrote:
>> Don wrote:
>>> Lars T. Kyllingstad wrote:
>>>> Denis Koroskin wrote:
>>>>> On Thu, 29 Oct 2009 15:12:51 +0300, Lars T. Kyllingstad 
>>>>> <public at kyllingen.nospamnet> wrote:
>>>>>
>>>>>> Jason House wrote:
>>>>>>> Andrei Alexandrescu Wrote:
>>>>>>>
>>>>>>>> It's a rough rough draft, but one for the full chapter on 
>>>>>>>> arrays, associative arrays, and strings.
>>>>>>>>
>>>>>>>> http://erdani.com/d/thermopylae.pdf
>>>>>>>>
>>>>>>>> Any feedback is welcome. Thanks!
>>>>>>>  I still think is expressions are a glaring problem. Somewhere in 
>>>>>>> the text, you use assert(!is(typeof(... as support for what 
>>>>>>> you're talking about. That particular construct feels more like a 
>>>>>>> hack someone stumbled into than clean, easy to read code. It's 
>>>>>>> the type of thing a programmer will get wring unless they use it 
>>>>>>> frequently. Even you've screwed it up in past Phobos releases!  
>>>>>>> IMHO all is(...) expressions should be revisited. Have you 
>>>>>>> written the section(s) on them yet?
>>>>>>
>>>>>> I don't think he uses is(typeof(...)) in the text. The code 
>>>>>> snippets in question are marked "Note: normally the code below 
>>>>>> would not be included...", and I suppose he's put them there as a 
>>>>>> reminder for himself and Walter on what needs to be fixed before 
>>>>>> the book comes out.
>>>>>>
>>>>>> I agree with you, though, is(typeof(...)) is quite often misused, 
>>>>>> or at least used in an ugly way. Why not use __traits(compiles, 
>>>>>> ...) instead?
>>>>>>
>>>>>> -Lars
>>>>>
>>>>> ... which is at least as ugly.
>>>>
>>>>
>>>> I disagree. Pretend you are just learning D, and you are presented 
>>>> with the following two lines of code:
>>>>
>>>>   static assert (is(typeof(XXX));
>>>>   static assert (__traits(compiles, XXX));
>>>>
>>>> Which of these would you most likely assume to be a check on whether 
>>>> XXX is compilable code?
>>>>
>>>> What I cannot for the life of me understand is WHY the double 
>>>> underscores? What's wrong with just "traits"?
>>>>
>>>> -Lars
>>>
>>> Also is(typeof(XXX)) *doesn't* currently check that XXX is 
>>> compilable, just that it has a type.
>>> OTOH __traits(compiles, XXX) is ugly. traits(compiles, XXX) would be 
>>> better; but I think we need to do better than that. It's the 
>>> bread-and-butter of metaprogramming in D. Using the ugly syntax, it 
>>> has well and truly proved its value.
>>> I've counted 20 uses in what I've seen of Andrei's book -- it appears 
>>> about as often as (say) 'delegate'!
>>>
>>> It does a beautiful thing, it deserves a beautiful syntax. Something 
>>> at least as good as __compiles(XXX), I reckon.
>>
>> Again with the double underscores. :)
> Yes. That's why I said "at least as good".
> 
>  I'm starting to think we need a
>> separate namespace for the CT stuff.
>>
>>   D.compiles(XXX)
>>   D.typeof(foo)
>>   D.stringof(T)
>>   D.allMembers(T)
> 
> That's not bad. Can't be 'D', though, has to look like a keyword. Maybe 
> something like 'traits' instead. In exchange, get rid of the '__traits' 
> and 'typeid' keywords. Not sure about typeof, though.
> 
> traits.compiles(XXX)
> traits.typeid(TTT)
> traits.stringof(T)
> traits.allMembers(T)
> traits.error("message");
> 
> IMHO this looks better than __traits(compiles, XXX) but it actually has 
> the same flexibility, and it's a straightforward transformation inside 
> the compiler.
> For bonus points, allow 'with(traits)':
> 
> with(traits) {
>   if (compiles(XXX)) return stringof(T);
>   else error("Can't use " ~ stringof(T) ~ " in a transmogrifier.");
> }

I like it. It's a clean, simple solution. The std.traits module will 
just have to be renamed to std.meta or something. Or one could possibly 
use 'meta' as the new keyword:

   meta.compiles(XXX)
   meta.typeid(T)
   meta.stringof(T)

Actually, I think I like that better than 'traits'.

-Lars