On 9/19/14, 11:32 PM, Vladimir Panteleev wrote:
> On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote:
>> [snip]
>
> Um, why not use __FILE__ / __LINE__ (as default values for template
> parameters) as cookies?

We could, but that would be surprising. I'd say things are good as they are. -- Andrei

On 9/19/14, 11:36 PM, Marco Leise wrote:
> Am Fri, 19 Sep 2014 08:02:30 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>
>> On 9/18/14, 11:45 PM, Marco Leise wrote:
>>> We should probably revert to having real typedefs.
>>
>> Should not.
>
> Ok, but don't ask me to use
>    alias ALfloat = std.typecons.Typedef!(float, "yummyCookie23");
> when it could be
>    typedef ALfloat = float;
> ! :)

I think this is an entirely palatable idiom:

alias ALfloat = std.typecons.Typedef!(float, "ALfloat");


Andrei

On 9/19/14, 11:50 PM, Dicebot wrote:
> On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote:
>> This is wrong but probably not worth fighting. Consider:
>>
>> alias A = Typedef!float;
>> alias B = Typedef!float;
>>
>> By basic language rules, A and B are identical. Making them magically
>> distinct would be surprising and would require explanation. It's as if
>> someone writes:
>>
>> struct Point { int x, y; }
>> alias A = Point;
>>
>> and then later in the same module
>>
>> alias B = Point;
>
> But Typedef is not some generic symbol. It is library type specifically
> introduced as `typedef` keyword replacement and advertised as such. I
> expect it to work as close to `typedef` as possible being the most
> priority. Otherwise it is simply useless.

No. -- Andrei

On Saturday, 20 September 2014 at 15:26:37 UTC, Andrei Alexandrescu wrote:
>> But Typedef is not some generic symbol. It is library type specifically
>> introduced as `typedef` keyword replacement and advertised as such. I
>> expect it to work as close to `typedef` as possible being the most
>> priority. Otherwise it is simply useless.
>
> No. -- Andrei

I don't really care what you think. There is a simple fact - there is not a single use case I am going to use existing implementation instead of rolling one of my own. Call me a pervert but when standard library type can't be used for something it was initially proposed for it does smell like a failure.

On 09/20/2014 06:52 AM, Andrei Alexandrescu wrote:
> On 9/19/14, 8:14 PM, Timon Gehr wrote:
>> ....
>> To substantiate: It does the wrong thing (same typedef for same base
>> type) by default and doing the right thing (emulating nominal typing)
>> may require quite some effort in general (e.g. concatenate the mangled
>> names of all enclosing template instantiations) while remaining
>> non-modular (those cookie strings are global identifiers).
>
> This is wrong

Well, how?

> but probably not worth fighting.

"Then don't bring it up." :o)

> Consider:
>
> alias A = Typedef!float;
> alias B = Typedef!float;
>
> By basic language rules, A and B are identical.

I don't see the relevance, but the definition of Typedef is also important to decide whether they are identical, not just language rules.

> Making them magically distinct ...

(Straw man.)

>
> Human-readable cookies are exactly the solution: distinct human-readable
> moniker that distinguish the types.
>
> alias A = Typedef!(float, "dollar");
> alias B = Typedef!(float, "euro");
> ...

This doesn't compile. This, IMHO more _ugly_, code compiles:

import std.typecons;
alias A = Typedef!(float, float.init, "dollar");
alias B = Typedef!(float, float.init, "euro");

// (different issue:
void main(){
    A dollars=2;
    B euros=2*dollars;
}//)

> They will be distinct to the human and compiler alone.
> ...

Library A:
alias A = Typedef!(int, -1, "handle");

Library B:
alias B = Typedef!(int, -1, "handle");

// ---

template Fun(S,T)/+if(...)+/{
    alias Hun=Typedef!(S,S.init,"hun");
    // (BTW: what do I do if S or T has no default initializer?)
    alias Gun=Typedef!(T,T.init,"gun");
    // ...
}

Now e.g. Fun!(int,double).Hun is compatible with Fun!(int,string).Hun.

This was my argument. IMO this state of affairs is ugly. Disagree that this makes the cookie parameter an 'ugly wart', but don't call the argument factually wrong without substantiation, please.

> ...
>
> Your argument has been destroyed.
>...

My argument hasn't been considered. To destroy its relevance without consideration would need a very compelling case for the beauty of the cookie parameter, which I haven't seen yet, and it is hard for me to imagine it being made without addressing the above issues. And besides, it is probably highly subjective. Apparently you find the cookie parameter to be pretty because it seems to work for the dollar/euro example (after fixing), while I have a different set of expectations.

(BTW: Note that I am not arguing for bringing back built-in typedef.)

On Sat, 20 Sep 2014 08:25:17 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> I think this is an entirely palatable idiom:
> alias ALfloat = std.typecons.Typedef!(float, "ALfloat");
this is ugly. even if we remove "std.typecons." it's still ugly. making such core feature ugly is the right way to marginalize it. "what? all this uglyness only for simple typedef? screw it, i'll go with simple `alias ALfloat = float;`! oh, wait... this gives me nothing and i already messed some declarations... ah, screw it, will use `float` then!"

the whole thing with aliasing Typedef is broken. yes, it's smart to use library for this (see, our language is THAT powerful!), but it's uuugly.

the same thing as with octal literals: we have 0b, we have 0x, yet it's very smart to banish octals to phobos and use octal!"660" instead of logical 0o660. phew.

but i know: octal literals are handy, so they will never make their way to mainline. "typedef" construct is handy, so...

Timon Gehr:

>> alias A = Typedef!(float, "dollar");
>> alias B = Typedef!(float, "euro");
>> ...
>
> This doesn't compile. This, IMHO more _ugly_, code compiles:
>
> import std.typecons;
> alias A = Typedef!(float, float.init, "dollar");
> alias B = Typedef!(float, float.init, "euro");

See:
https://d.puremagic.com/issues/show_bug.cgi?id=11828

Some other open issues/ERs:
https://issues.dlang.org/buglist.cgi?f1=short_desc&o1=casesubstring&query_format=advanced&resolution=---&v1=Typedef

Bye,
bearophile

ketmar:

> but i know: octal literals are handy, so they will never make their way to mainline. "typedef" construct is handy, so...

A well working Typedef/typedef (named "newtype" in Haskell, where it's a built-in) is more commonly useful than octal literals.

Bye,
bearophile

On Saturday, 20 September 2014 at 13:49:58 UTC, Marco Leise wrote:
> Am Sat, 20 Sep 2014 06:32:38 +0000
> schrieb "Vladimir Panteleev" <vladimir@thecybershadow.net>:
>
>> On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote:
>> > [snip]
>> 
>> Um, why not use __FILE__ / __LINE__ (as default values for template parameters) as cookies?
>
> It has this nasty imperfection that it breaks as soon as you
> define two Typedefs on the same line. Which noone ever does
> except maybe for an obfuscated coding scenario, but still it
> raises my OCD level.

We could introduce __COLUMN__ trivially now that DMD tracks column numbers :)

On 9/20/14, 8:51 AM, Dicebot wrote:
> On Saturday, 20 September 2014 at 15:26:37 UTC, Andrei Alexandrescu wrote:
>>> But Typedef is not some generic symbol. It is library type specifically
>>> introduced as `typedef` keyword replacement and advertised as such. I
>>> expect it to work as close to `typedef` as possible being the most
>>> priority. Otherwise it is simply useless.
>>
>> No. -- Andrei
>
> I don't really care what you think.

You should if I'm right :o).

> There is a simple fact - there is
> not a single use case I am going to use existing implementation instead
> of rolling one of my own. Call me a pervert but when standard library
> type can't be used for something it was initially proposed for it does
> smell like a failure.

But it can be used. You are quick to claim "failure" just because you can't bring yourself to use a simple idiom. Type the blessed string and you're done.

So my understanding is your reasoning goes like this:

alias Dollar = Typedef!double; // fantastic
alias Dollar = Typedef!(double, "Dollar"); // failure

I would agree it's not as convenient as a built-in language feature, but it's eminently usable and in fact quite nice because it gives you access to a nice moniker that can be used, e.g.

alias Dollar = Typedef!(double, "$"); // yum

In the latter case you go on your own and write a bunch of code because you refuse to... type a few characters. I hope you understand why it's difficult to carry any compelling point with such arguments.


Andrei