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