"Marco Leise"  wrote in message news:20140920155851.030b1633@marco-leise.homedns.org...

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

Or inside a template, but that breaks with an explicit cookie as well.

template Foo(T)
{
   alias FooIndex = Typedef!(int, "FooIndex");
}

static assert(!is(Foo!int == Foo!string)); 

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.

https://github.com/D-Programming-Language/phobos/pull/300#issuecomment-3329507

On Saturday, 20 September 2014 at 17:05:40 UTC, Daniel Murphy wrote:
> "Marco Leise"  wrote in message news:20140920155851.030b1633@marco-leise.homedns.org...
>
>> 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.
>
> Or inside a template, but that breaks with an explicit cookie as well.
>
> template Foo(T)
> {
>    alias FooIndex = Typedef!(int, "FooIndex");
> }
>
> static assert(!is(Foo!int == Foo!string));

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

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

Andrei Alexandrescu:

> But it can be used.

Have you used it in your real D code three or more times? I have tried and I have found many problems.

Bye,
bearophile

On 9/20/14, 9:07 AM, Timon Gehr wrote:
> 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)

Fair enough. It's just that... the tanks are coming and I'm to worry about the bayonet needing some grease instead of setting up the shaped charges. It's misplaced focus.

>> 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");

Uhm, apparently I haven't tried the code :o). (Well prolly I'd want to use 0.0 as initializer there, too.)

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

Ew, that looks like a bug. How does that conversion go through? Could you please file an issue?

>> 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");
>
> // ---

Yup, yup, say no more. I get your point. Clearly there's some due diligence necessary here, i.e. prefix the name with the module name etc.

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

OK, fair enough. Thanks.


Andrei

On 9/20/14, 9:32 AM, ketmar via Digitalmars-d wrote:
> 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.

But not unusable.

> 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!"

Are you saying you're giving up on an entire design because you can't bring yourself to type one string?

> the whole thing with aliasing Typedef is broken.

s/broken/less convenient than a builtin/ and we agree.

> yes, it's smart to use
> library for this (see, our language is THAT powerful!), but it's uuugly.

uuugly != broken

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

Not sure I understand this last point. At any rate, if your entire line of reasoning hinges on you being unwilling to type a few more characters to have a workable solution, I have difficulty taking it seriously.


Andrei

On 9/20/14, 10:13 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> But it can be used.
>
> Have you used it in your real D code three or more times?

No, but that doesn't mean much.

> I have tried
> and I have found many problems.

Then fix them. Most of the stuff at https://issues.dlang.org/buglist.cgi?f1=short_desc&list_id=106755&o1=casesubstring&query_format=advanced&resolution=---&v1=Typedef is trivially fixable. Should take you all of a morning to fix most or all of those. Just do it!


Andrei

On Sat, 20 Sep 2014 10:20:28 -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.
> But not unusable.
tying code using my nose is entirely possible too, and it even fun. but it's far from being "usable technique".

> Are you saying you're giving up on an entire design because you can't bring yourself to type one string?
not just one string. people will use ugly features only when they are forced to. D makes using typedefs unnecessarily ugly, thus marginalising them. turn struct declaration to "Declare!struct" and leave class declaration as-is, and people will start use classes instead of structs, even when struct is better fit. or remove "string" alias.

what i'm trying to say is that "typedef" is "core feature" if we are talking about type safety, and it should be nice or people will not use it. current "Typedef" is not nice.

> > the whole thing with aliasing Typedef is broken.
> s/broken/less convenient than a builtin/ and we agree.
no, it is broken. for such important feature "less convient" means "broken".

> uuugly != broken
"==" for this case.

> Not sure I understand this last point. At any rate, if your entire line of reasoning hinges on you being unwilling to type a few more characters to have a workable solution, I have difficulty taking it seriously.
i don't want "workable solution", i want "usable solution". "Typedef" is barely usable due to being one of fundamental features and uuugly. make something ugly and people will avoid it as much as they can. if we don't care about compile-time type safety... ok, let it stay ugly.

On Sat, 20 Sep 2014 16:36:49 +0000
bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> A well working Typedef/typedef (named "newtype" in Haskell, where it's a built-in) is more commonly useful than octal literals.
i'm not saying that octal literals are in much need, i'm talking about
consistency (again).

On 9/20/14, 10:49 AM, ketmar via Digitalmars-d wrote:
> i don't want "workable solution", i want "usable solution".

Guess a copyediting pass would have caught that one. -- Andrei