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 > >>>>> <pub...@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
