Thu, 24 Sep 2009 19:44:09 +0000, language_fan thusly wrote: > Thu, 24 Sep 2009 15:33:38 -0400, Jarrett Billingsley thusly wrote: > >> On Thu, Sep 24, 2009 at 2:36 PM, Aenigmatic <[email protected]> >> wrote: >>> No further response to any responses to my previous post's responses >>> is a both swift and non-invasive. >>> >>> Now my deeply thought question is ... >>> >>> Is typedef (in D) a C/C++ legacy or is the dear orphan now adopted as >>> a first-class citizen in the US of D? >> >> It's a different beast, and in my experience, pretty useless. Most of >> the time you want typedef'ed types to interact with other types a >> little more richly. Say you want to use a double as a time. Okay, what >> do you get when you subtract two points in time? Not a time, that's for >> sure. You get a time _span_ instead. So you end up implementing them as >> structs. >> >> Virtually every time I've tried to use typedef, it hasn't sufficed and >> I've ended up using a struct instead. It seems like a failed idea, or >> at the very least, yet another half-thought-out abandoned feature. > > I can imagine some uses for it when the type is very simple, and you > fear that the compiler cannot inline operations on structs. Other than > that, common mainstream language features like typedefs, variant!(), and > enums are mere special cases of algebraic datatypes (with some implicit > syntactic sugar). There are some downsides, too, but I prefer to have > the more general type in languages that I use.
If I recall correctly, one of the reasons that also make typedefs in D a bit more useless is the inconsistency in implicit casts. E.g. when you create a temperature type, I think some of the conversions between floats, Temperature, and literals fail.
