The Thermopylae excerpt of TDPL available online

Don nospam at nospam.com
Fri Oct 30 03:19:44 PDT 2009


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.");
}




More information about the Digitalmars-d mailing list