www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - So why was typedef bad?

reply Ethan Watson <gooberman gmail.com> writes:
http://dlang.org/deprecate.html#typedef

"typedef is not flexible enough to cover all use cases. This is 
better done with a library solution."

[Citation needed]

What use cases is it not flexible enough for?

This is tangentially related to my other topic about template 
visibility, specifically the alias I'm trying to do to my 
binderoo.math.vector.VectorFloat.

The problem with alias is that it won't instantiate an entirely 
new symbol. It's effectively a hard link to another symbol. 
Trying to resolve the module name won't actually give me what I 
want here.

Maybe the deprecated typedef will get me what I want? I can't 
make Visual D respect my -d command line properly, so I can't get 
in and quickly check if things are okay there.

Right, so off to the library solution, std.typecons.Typedef. Uh. 
This isn't a typedef. This embeds one type within another and 
tries to mimic that type as much as possible. And it makes that 
member private. You know what this means - if I try to parse over 
it for my serialisation pass for Binderoo, I can't use __traits( 
allMembers ) to get to it. Also, technically, since it's an 
object within an object it will need to double up on the JSON 
hierarchy to store it unless I get in and specialise it.

At the very least, it seems here that Typedef should actually be 
called TypeWrapper, it would actually make sense for its 
functionality there.

Which gets back to the keyword typedef. Sure, it's not as 
flexible as alias. And I don't even know if a typedef in one 
module would result in a symbol resolution to that module or not. 
But what was the actual problems with it?
Aug 31 2016
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 31 Aug 2016 13:44:51 +0000, Ethan Watson wrote:


 http://dlang.org/deprecate.html#typedef
 
 "typedef is not flexible enough to cover all use cases. This is better
 done with a library solution."
 
 [Citation needed]
 
 What use cases is it not flexible enough for?


Specifying the default value for the type. Making all typedefs from a 
base type implicitly convert to each other without warning unless you're 
careful, which should be a bug (the default discriminator should be 
__MODULE__ + __LINE__, and instead it's null).
Aug 31 2016
parent reply Ethan Watson <gooberman gmail.com> writes:
On Wednesday, 31 August 2016 at 14:05:16 UTC, Chris Wright wrote:

 Specifying the default value for the type.


Alias has the same problem in this case.


 Making all typedefs from a base type implicitly convert to each 
 other without warning unless you're careful, which should be a 
 bug.


Which sounds like unique types constructed from other types are 
wanted instead of a typedef.

At the very least, if those were the actual problems, then it 
seems like std.typecons.Typedef has been transformed in to 
something other than a typedef simply for the crime of typedef 
being a subset of alias' functionality. Dropping typedef might 
make sense in favour of alias, but redirecting to something 
entirely different in the official documents... I know I just 
wasted some time evaluating its usefulness at least.

I'm making a distinction here between a typedef and a type mimic 
here because C++ interop is a big factor in our usage, so mixing 
up concepts between a language that's meant to make that easy is 
not ideal. Although looking at std.typecons.Typedef, I'd wonder 
if a typemimic language feature would have been a better way to 
go...
Aug 31 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2016 7:31 AM, Ethan Watson wrote:

 On Wednesday, 31 August 2016 at 14:05:16 UTC, Chris Wright wrote:

 Specifying the default value for the type.


 Alias has the same problem in this case.


Alias is not a different type from the underlying type. So having a different 
default value makes no sense.



 I'm making a distinction here between a typedef and a type mimic here because
 C++ interop is a big factor in our usage, so mixing up concepts between a
 language that's meant to make that easy is not ideal. Although looking at
 std.typecons.Typedef, I'd wonder if a typemimic language feature would have
been
 a better way to go...


I don't understand. C++ typedef and D alias are semantically equivalent.

D's typedef was dropped because nobody could come up with a coherent
explanation 
of how implicit conversions should work to/from the base type. This is not the 
simple problem it appears to be. There are all kinds of issues, like how does 
type deduction work, type inference, when are the types the same, when are they 
different, promotion rules, etc. Furthermore, they add a lot of complexity to 
generic templates.

We finally just abandoned it.
Sep 04 2016
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 08/31/2016 06:44 AM, Ethan Watson wrote:


 And it makes that member private. You
 know what this means - if I try to parse over it for my serialisation
 pass for Binderoo, I can't use __traits( allMembers ) to get to it.


Hopefully, with enough whining we will have that behavior reversed. :) 
__traits(allMembers) should give "all members".

Ali
Aug 31 2016
prev sibling parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: So why was typedef bad?
References: <pajfgmhstwvavygmyizd forum.dlang.org>
In-Reply-To: <pajfgmhstwvavygmyizd forum.dlang.org>

--8Du0jjLxasSF0Gj8nQRblaKuB0iX6OkeW
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 08/31/2016 04:44 PM, Ethan Watson wrote:

 http://dlang.org/deprecate.html#typedef
=20
 "typedef is not flexible enough to cover all use cases. This is better
 done with a library solution."
=20
 [Citation needed]
=20
 What use cases is it not flexible enough for?


It has unadjustable semantics that were both more restrictive than alias
and at the same time not restrictive enough to introduce completely new
type. Wasn't supposed to be compatible with base type but sometimes did,
with no reasons other than "historical".

In my own experience creating dedicated struct type is always superior
to typedef if you want to go for type safety. It can start with simple
`alias this` struct to have permissive semantics similar to old typedef
and later changed to operator overloading for more fine tuned control.
It can also provide methods for verified conversion between base type
and new domain type.

And if type safety is not a goal, there isn't much point in all the
typedef restrictions and alias should do as well.


--8Du0jjLxasSF0Gj8nQRblaKuB0iX6OkeW--
Sep 01 2016