www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - typedef redux

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
next sibling parent Max Samukha <spambox d-coding.com> writes:
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
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
parent reply Justin Johansson <no spam.com> writes:
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
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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
parent Justin Johansson <no spam.com> writes:
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
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
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
prev sibling next sibling parent BLS <windevguy hotmail.de> writes:
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
prev sibling next sibling parent Ali Cehreli <acehreli yahoo.com> writes:
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
prev sibling parent reply Moritz Warning <moritzwarning web.de> writes:
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
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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