digitalmars.D - typedef redux
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Nov 12 2009
- Max Samukha <spambox d-coding.com> Nov 12 2009
- Sean Kelly <sean invisibleduck.org> Nov 12 2009
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Nov 12 2009
- Justin Johansson <no spam.com> Nov 12 2009
- Walter Bright <newshound1 digitalmars.com> Nov 12 2009
- Justin Johansson <no spam.com> Nov 19 2009
- Moritz Warning <moritzwarning web.de> Nov 13 2009
- BLS <windevguy hotmail.de> Nov 12 2009
- Ali Cehreli <acehreli yahoo.com> Nov 12 2009
- Moritz Warning <moritzwarning web.de> Nov 13 2009
My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good? Andrei
Nov 12 2009
On Thu, 12 Nov 2009 09:37:07 -0600, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good? Andrei
After having tried typedefs a couple of times, I gave up on them and have never regretted. I won't miss them.
Nov 12 2009
Andrei Alexandrescu Wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good?
I like that typedef purports to offer an inheritance model of sorts to concrete types. Aliasing is all well and good, but it isn't always appropriate. But I really haven't spent much time with typedef recently. From what I've read, it sounds like the implementation doesn't live up to the promise. Is this true?
Nov 12 2009
Sean Kelly wrote:Andrei Alexandrescu Wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good?
I like that typedef purports to offer an inheritance model of sorts to concrete types. Aliasing is all well and good, but it isn't always appropriate. But I really haven't spent much time with typedef recently. From what I've read, it sounds like the implementation doesn't live up to the promise. Is this true?
The current implementation is just broken because there was no definition of the feature. It just does the moral equivalent of what an unintended switch fall-through does :o). One basic problem was that Walter and I couldn't even make a water-tight case of which direction the inheritance should go: I thought typedef should introduce a subtype, and he thought it should introduce a supertype. We both had examples. We both saw the other's argument. We both realized the shortcomings of the feature, regardless of whatever direction we chose. We both saw the costs in the implementation and in the language definition, and we realized the paucity of benefits. So there's not only an implementation that doesn't live up to the promise, we even don't have a reasonable promise to fulfill. Andrei
Nov 12 2009
Andrei Alexandrescu Wrote:Sean Kelly wrote:Andrei Alexandrescu Wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good?
I like that typedef purports to offer an inheritance model of sorts to concrete types. Aliasing is all well and good, but it isn't always appropriate. But I really haven't spent much time with typedef recently. From what I've read, it sounds like the implementation doesn't live up to the promise. Is this true?
The current implementation is just broken because there was no definition of the feature. It just does the moral equivalent of what an unintended switch fall-through does :o). One basic problem was that Walter and I couldn't even make a water-tight case of which direction the inheritance should go: I thought typedef should introduce a subtype, and he thought it should introduce a supertype. We both had examples. We both saw the other's argument. We both realized the shortcomings of the feature, regardless of whatever direction we chose. We both saw the costs in the implementation and in the language definition, and we realized the paucity of benefits. So there's not only an implementation that doesn't live up to the promise, we even don't have a reasonable promise to fulfill.
"One basic problem was that Walter and I couldn't even make a water-tight case of which direction the inheritance should go: I thought typedef" I remember the discussion ... and if two intelligent folks in language design can't agree on "inheritance direction" ... and given the paucity of benefits ... there is only one reasonable promise to fulfill ... D. typedef 2006 - 2009 RIP
Nov 12 2009
Justin Johansson wrote:I remember the discussion ... and if two intelligent folks in language design can't agree on "inheritance direction" ... and given the paucity of benefits ... there is only one reasonable promise to fulfill ... D. typedef 2006 - 2009 RIP
Yeah, that's why I asked here to see if we'd missed something important. Looks like we haven't. Typedef is getting the boot in D2.
Nov 12 2009
Walter Bright wrote:Justin Johansson wrote:I remember the discussion ... and if two intelligent folks in language design can't agree on "inheritance direction" ... and given the paucity of benefits ... there is only one reasonable promise to fulfill ... D. typedef 2006 - 2009 RIP
Yeah, that's why I asked here to see if we'd missed something important. Looks like we haven't. Typedef is getting the boot in D2.
I noticed that many if not all the typedef related bugs have been marked as rectified in the bug tracker by virtual of them no longer being applicable. Congrats on the speedy remedy!!!
Nov 19 2009
On Thu, 12 Nov 2009 13:07:24 -0800, Walter Bright wrote:Justin Johansson wrote:I remember the discussion ... and if two intelligent folks in language design can't agree on "inheritance direction" ... and given the paucity of benefits ... there is only one reasonable promise to fulfill ... D. typedef 2006 - 2009 RIP
Yeah, that's why I asked here to see if we'd missed something important. Looks like we haven't. Typedef is getting the boot in D2.
Arrr, let it walk the plank!
Nov 13 2009
On 12/11/2009 16:37, Andrei Alexandrescu wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good? Andrei
typedef uint NON_CRITICAL_SPEED ( 200..350 ) sugar for : template NON_CRITICAL_SPEED(T = uint) if( T > 199 && T < 351) { ... } but well, just a quick 'n dirty idea
Nov 12 2009
Andrei Alexandrescu Wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types.
I've just started experimenting with typedef to see whether it would allow subtyping dchar. I wanted to have a typedef'ed 'trchar' (Turkish character) that would use specialized functions for capitalization and sorting. My short experimentation started promising. Although, I would love to say 'a'tr, or "abc"tr too, which may not exist in D2. (I think C++0x is bringing a similar feature.) Is typedef good for what I've been trying to do without using a full-fledged class? Can I use alias? It would be nice to be able to use the same syntax as dchar and dstring. Ali
Nov 12 2009
On Thu, 12 Nov 2009 09:37:07 -0600, Andrei Alexandrescu wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good? Andrei
Sounds good to me. typedef void* FooRef; can be replaced by (at least in most cases): struct Foo {}; alias Foo* FooRef;
Nov 13 2009
Moritz Warning wrote:On Thu, 12 Nov 2009 09:37:07 -0600, Andrei Alexandrescu wrote:My perception following the discussion around typedef is that we should eliminate it. What we offer is "alias", which is a generalization of C's "typedef", and the change of name is justified by the fact that "alias" defines aliases for more entities than just types. Does all that sound good? Andrei
Sounds good to me. typedef void* FooRef; can be replaced by (at least in most cases): struct Foo {}; alias Foo* FooRef;
Even better: struct Foo; alias Foo* FooRef; That way people won't be able to erroneously pass Foo by value. Andrei
Nov 13 2009









Max Samukha <spambox d-coding.com> 