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
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
next 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 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 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


IMO typedef should enable sub-types

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