"Vladimir Panteleev"  wrote in message news:oadjpzibjneyfutoydct@forum.dlang.org...

> What if you *want* a Typedef instantiation to be the same for all instantiations of a parent template?

Declare it outside the template and provide an alias inside.  Like you would with any other declaration you wanted common to all instantiations.

> I think you can have both if Typedef simply takes an "ARGS...", which defaults to TypeTuple!(__FILE__, __LINE__, __COLUMN__), but in this case can be overridden to TypeTuple!(Foo, T).

Yeah.  If it wasn't for the syntax overhead, the ideal args is something like this:

struct MyTypedef_Tag;
alias MyTypedef = Typedef!(basetype, init, MyTypedef_Tag); 

On 9/22/14, 11:35 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I find the requirement for the cookie perfect.
>
> So far you're the only one, it seems. And you have admitted you have not
> tried to use them significantly in your code.

Well there seem to be a sore need of arguments to convince me otherwise. Best one was a triple "u" in "ugly". -- Andrei

On 9/22/14, 11:52 AM, ketmar via Digitalmars-d wrote:
> seems that Andrei talking about 'idiomatic D' and we are talking about
> 'hacky typedef replacement'. that's why we can't settle the issue: we
> are both right! ;-)

That I'd agree with.

> and that's why we need 'typedef' revived, methinks.

Sorry, no.


Andrei

On 9/22/14, 11:56 AM, Daniel Murphy wrote:
> "Vladimir Panteleev"  wrote in message
> news:oadjpzibjneyfutoydct@forum.dlang.org...
>
>> What if you *want* a Typedef instantiation to be the same for all
>> instantiations of a parent template?
>
> Declare it outside the template and provide an alias inside.  Like you
> would with any other declaration you wanted common to all instantiations.
>
>> I think you can have both if Typedef simply takes an "ARGS...", which
>> defaults to TypeTuple!(__FILE__, __LINE__, __COLUMN__), but in this
>> case can be overridden to TypeTuple!(Foo, T).
>
> Yeah.  If it wasn't for the syntax overhead, the ideal args is something
> like this:
>
> struct MyTypedef_Tag;
> alias MyTypedef = Typedef!(basetype, init, MyTypedef_Tag);

struct MyTypedef_Tag;
alias MyTypedef = Typedef!(basetype, init, MyTypedef_Tag.mangleof);

should get you off the ground :o).


Andrei

What exactly was wrong with the original typedef statement that was deprecated?

On Tuesday, 23 September 2014 at 00:01:51 UTC, Shammah Chancellor wrote:
> What exactly was wrong with the original typedef statement that was deprecated?

I personally find it too inflexible; it virtually never does exactly what I need. BTW I've never used std.typecons.Typedef for the same reason.

But what are some examples of typedef? HANDLE and HMENU are close to useful indeed, I've used typedef for that kind of thing before. But it isn't perfect: do you ever want do do *handle? That's allowed with typedef. Do you want it to explicitly cast to void*? That's allowed with typedef.

People couldn't agree on if typedef should be a subtype or a separate type either, which fed the deprecation. Personally though I think that's silly, if what it does is well defined, we can keep it and do other things for the other cases. But it does need to be compelling over another feature to be kept and I'm not sure it is.

So I tend to prefer struct and a little alias this and disabled overloads to a typedef. A wee bit more verbose, but more flexible and correct too.

On Tue, Sep 23, 2014 at 12:13:19AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 23 September 2014 at 00:01:51 UTC, Shammah Chancellor wrote:
> >What exactly was wrong with the original typedef statement that was deprecated?
> 
> I personally find it too inflexible; it virtually never does exactly what I need. BTW I've never used std.typecons.Typedef for the same reason.
> 
> But what are some examples of typedef? HANDLE and HMENU are close to useful indeed, I've used typedef for that kind of thing before. But it isn't perfect: do you ever want do do *handle? That's allowed with typedef. Do you want it to explicitly cast to void*? That's allowed with typedef.
> 
> People couldn't agree on if typedef should be a subtype or a separate type either, which fed the deprecation. Personally though I think that's silly, if what it does is well defined, we can keep it and do other things for the other cases. But it does need to be compelling over another feature to be kept and I'm not sure it is.
> 
> So I tend to prefer struct and a little alias this and disabled overloads to a typedef. A wee bit more verbose, but more flexible and correct too.

Yeah, I think struct + alias this + function/operator overloading pretty much does whatever typedef may have done, except better. So I personally don't miss typedef at all (not Typedef, for that matter).


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

On Mon, 22 Sep 2014 16:05:38 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> Best one was a triple "u" in "ugly".
there were four "u"s, but my mail program makes uuugly like breaks with four "u"s.

On Mon, 22 Sep 2014 16:06:42 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 9/22/14, 11:52 AM, ketmar via Digitalmars-d wrote:
> > seems that Andrei talking about 'idiomatic D' and we are talking about 'hacky typedef replacement'. that's why we can't settle the issue: we are both right! ;-)
> That I'd agree with.
yeah, and then your resistance to turn 'idiomatic D' to 'hacky typedef' is completely understandable. it took me a while to realise that we are talking about different things here.

> > and that's why we need 'typedef' revived, methinks.
> Sorry, no.
"Typedef" is elegant and "typedef" is handy. why can't we have both? at least until AST macros arrives (and then we'll make "typedef", "deftype" and "gimmeacheese" ;-). let's limit "typedef" to simple numeric types and pointers to simple numeric types to ease implementation. sure, we'll be able to multiple money by money but not money by float then, but i found this acceptable, we always can write a free function which multiples our money. ;-)

On Monday, 22 September 2014 at 14:56:26 UTC, Andrei Alexandrescu wrote:
> On 9/22/14, 2:39 AM, Don wrote:
>> On Sunday, 21 September 2014 at 18:09:26 UTC, Andrei Alexandrescu wrote:
>>> On 9/21/14, 8:29 AM, ketmar via Digitalmars-d wrote:
>>>> On Sun, 21 Sep 2014 08:15:29 -0700
>>>> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
>>>> wrote:
>>>>
>>>>> alias Int1 = Typedef!(int, "a.Int1");
>>>>> alias Int2 = Typedef!(int, "b.Int2");
>>>> ah, now that's cool. module system? wut? screw it, we have time-proven
>>>> manual prefixing!
>>>
>>> Use __MODULE__. -- Andrei
>>
>>
>> Yes, but you're advocating a hack.
>
> Oh but I very much disagree.

Now you are scaring me. It worries me that this kind of "solution" can be viewed as acceptable. It's the kind of hacky code I left C++ to escape from.

People in this thread said it was "ugly" and you dismissed that. But this isn't just a matter of personal aesthetics.
If you want something objective, it's not DRY, and it's verbose in a non-trivial way. The hacky design leads to error-prone code.
eg you can easily get a copy-paste bug because it's not DRY.

alias HMENU = Typedef!(void*, __MODULE__ ~ ".HMENU");
alias HFONT = Typedef!(void*, __MODULE__ ~ ".HMENU"); // oops


>> The original premise does seem to be
>> correct: library Typedefs are fundamentally broken. The semantics of
>> templates does not match what one expects from a typedef: ie, declaring
>> a new, unique type.
>>
>> If you have to pass __MODULE__ in, it's not really a library solution.
>> The user code needs to pass in a nasty implementation detail in order to
>> get a unique type.
>
> How many libraries did you use that came with no idioms for their usage?

Describing this as an "idiom" is extremely generous. My standards are higher.


>> And it does seem to me, that because it isn't possible to do a proper
>> library typedef, you've attempted to redefine what a Typedef is supposed
>> to do. And sure, it you remove the requirement to create a unique type,
>> Typedef isn't broken.
>
> You're two paragraphs away from "library Typedefs are fundamentally broken". Now which one is it?

Phobos' Typedef is fundamentally broken, and that your claim that it is not, relies on moving the goalposts.

>> But then it isn't very useful, either. You can't,
>> for example, use it to define the various Windows HANDLEs (HMENU, etc),
>> which was one of the most successful use cases for D1's typedef.
>
> alias HMENU = Typedef!(void*, __MODULE__ ~ ".HMENU");
>
> So please s/can't/can't the same exact way built-in typedef would have done it/.

No. You can hammer nails in using a rock, but I'm not prepared to accept a rock as a kind of hammer. It's not a tool that belongs in any toolbox.

My assertion is, there are no use cases for Phobos's Typedef.
You're always better off doing something else.