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?

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).

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

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

On 08/31/2016 04:44 PM, 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?

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.

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.