On Mon, 07 May 2012 15:48:22 -0400, Mehrdad <[email protected]> wrote:
On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
I think it was more that the whole concept was flawed -- typedef int
myint never really did exactly what you wanted it to.
For example:
myint m = 1; // ok
m += 5; // ok
m = m + 5; // error?
It's definitely an error, because 5 isn't myint.
Of course, it wouldn't be an error in C code, but keeping source
compatibility isn't a goal either.
I'm looking at this:
m += 5; // ok
m = m + 5; // error
And thinking, hm.. this is no good :)
C compatibility is not what we are after here, alias already handles C
compatibility.
Wouldn't a global search-and-replace that replaced "typedef" with
"alias" when porting C code have fixed 99% of this issue, practically
speaking?
No, it's not a portability issue. It's a WTF issue.
Things got even worse when you weren't typedef'ing a basic type.
It sounds so trivial to fix though (especially since it's not silent
breakage)...
Would you mind giving another (actual) example (perhaps with a custom
type?) that came up, and which shows the extent of the problem and why
it was difficult to solve without disallowing typedef entirely?
I'm having a hard time seeing why the problem was so difficult (or
tedious) to fix... a search/replace for typedef/alias would've fixed all
(or almost) all the cases when porting C code, right?
I'm almost 100% certain that the issues had nothing to do with C
compatibility. It was all in how D typedefs behaved strangely.
Not being one to have used them much, I can only recollect that one
example. I do remember people bitching about them quite a bit, and nobody
really having any good ideas on how to fix them, but I don't know circa
what time period to look for those discussons. One person who was an
ardent supporter of typedefs, and still wants *something* like them is
bearophile. He might be able to list some issues/find some old posts/bugs
that make more sense.
-Steve
