On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote:
Right, but what I was saying was that that *isn't* what it's
meant to be! It's just a *size* type, not a *word* of any
kind... (think about systems with interleaving pointers, for
example, x86 with segmentation -- the notion of a "word" isn't
so obvious anymore, when denoting sizes)
Yeah, figuring out what to name something is always a challenge,
and the huge variety and complexity of modern, and even
not-so-modern processors doesn't help at all.
There definitely needs to be way to define a type that can't
implicitly cast to its base type. The problem is that the
original typedef did do implicit casting away, and that has
potential to cause confusion when porting from C or D1. I
don't see that as much of a problem, but others might.
Yeah, I still don't understand what the "potential to cause
confusion" was.
Was it *actually* causing a significant problem, or was it just
a "potential" problem?
The issue is if someone new to D2 is porting code from C or D1,
they would get all kinds of weird errors caused by using typedef
instead of D2's alias and trying to do math or expecting implicit
casting to work. But D2 is a different language, with different
syntax and semantics. Anyone expecting copied C to "just work" in
D2 is expecting a miracle, but that's not to say we can't try to
make it as easy as possible.
IMO, alias is a much better name than typedef, which is quite
generic because technically any struct, class, or even function
declaration is defining a new type. But adding a new keyword is
ugly, assuming you can think of a good one, so typedef is
probably the best choice. The only other alternative is reusing
existing keywords, but I can't even think of a good choice. Does
any of static/const/immutable/etc. alias sound good to anyone?
