The Thermopylae excerpt of TDPL available online

[Justin Johansson]

Lars T. Kyllingstad Wrote:

> 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

I'm in agreement with whoever suggested 'meta' or just about anything else except  'traits'.
'meta', whilst perhaps an overloaded keyword, is still much more user-friendly.  Whenever
I see 'traits' I get the feeling I need a Ph.D. to understand what it's about.  For some reason,
I don't know why, 'meta' has an aire of karma about it.

Justin