https://issues.dlang.org/show_bug.cgi?id=12597

Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com

--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
Looks fairly innocent, but what if the original type is a user-defined type that already defines the get() method?

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #2 from bearophile_hugs@eml.cc ---
(In reply to Andrej Mitrovic from comment #1)

> what if the original type is a user-defined type
> that already defines the get() method?

Then perhaps you need to write this?

auto y3 = sin(x.get.get);

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
(In reply to bearophile_hugs from comment #2)
> (In reply to Andrej Mitrovic from comment #1)
> 
> > what if the original type is a user-defined type
> > that already defines the get() method?
> 
> Then perhaps you need to write this?
> 
> auto y3 = sin(x.get.get);

That would cause existing and generic code to break. For example:

-----
module test;

import std.typecons;

struct S
{
    int get() { return 0; }
}

alias S2 = Typedef!S;

void main()
{
    S2 s2;
    auto x = s2.get();  // works now
}
-----

If we want a solid Typedef in D2 then we have to take this into account as well.

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #4 from bearophile_hugs@eml.cc ---
(In reply to Andrej Mitrovic from comment #3)

> That would cause existing and generic code to break.

I see. On the other hand currently Typedef has several problems, and all or almost all bug reports/ERs on it are mine, so I doubt there is a lot of existing code that uses it :-)

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #5 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
(In reply to bearophile_hugs from comment #4)
> (In reply to Andrej Mitrovic from comment #3)
> 
> > That would cause existing and generic code to break.
> 
> I see. On the other hand currently Typedef has several problems, and all or almost all bug reports/ERs on it are mine, so I doubt there is a lot of existing code that uses it :-)

Yeah I know. But there are plenty of people on IRC that keep asking about it though, I typically don't recommend them to use Typedef since it's full of bugs.

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #6 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
You seem to have filed https://issues.dlang.org/show_bug.cgi?id=11706 before, maybe we should just implement that instead? Then the cast would be safe.

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #7 from bearophile_hugs@eml.cc ---
(In reply to Andrej Mitrovic from comment #5)

> there are plenty of people on IRC that keep asking about it
> though, I typically don't recommend them to use Typedef since it's full of
> bugs.

While not strictly necessary, something like typedef/Typedef is sometimes useful. In Haskell there's a built-in way to do it, using "newtype", and the GHC compiler has one or more non-standard extensions (GeneralizedNewtypeDeriving) to improve the use of newtype.


(In reply to Andrej Mitrovic from comment #6)
> You seem to have filed https://issues.dlang.org/show_bug.cgi?id=11706 before, maybe we should just implement that instead? Then the cast would be safe.

The need to find the underlying type and the underlying value are both present. So I think we need both enhancements. (I have also just added a note to Issue 11706 ). If you want to implement only one of the two, then I suggest to implement a way to get the underlying value, because then getting the type is one typedef away.

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #8 from bearophile_hugs@eml.cc ---
(In reply to bearophile_hugs from comment #7)

>because then getting the type is one typedef away.

Sorry, I meant to write one typeof away.

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #9 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
Would this getter give ref access? If so, we might as well make the `Typedef_payload` field public. Otherwise we could make a UFCS function that would avoid symbol conflicts:

-----
V getValue(T)(T t)
    /* if (isTypedef!T) */
{
    return t.Typedef_payload;
}
-----

This would be usable via:

Typedef!Type x;
x.getValue();  // assuming 'Type' doesn't define getValue
getValue(x);   // workaround if 'Type' *does* define getValue

Let me know what you think.

--

https://issues.dlang.org/show_bug.cgi?id=12597

--- Comment #10 from bearophile_hugs@eml.cc ---
(In reply to Andrej Mitrovic from comment #9)

> we might as well make the `Typedef_payload` field public.

Yes, making that field public could be the simplest solution. But the field needs to be renamed to a nicer/shorter name, perhaps like "_data".


> Otherwise we could make a UFCS function that
> would avoid symbol conflicts:
> 
> -----
> V getValue(T)(T t)
>     /* if (isTypedef!T) */
> {
>     return t.Typedef_payload;
> }
> -----
> 
> This would be usable via:
> 
> Typedef!Type x;
> x.getValue();  // assuming 'Type' doesn't define getValue
> getValue(x);   // workaround if 'Type' *does* define getValue
> 
> Let me know what you think.

Seems good, but to reduce the frequency of name clashes I'd like a less generic/common name, like "typedefVal". And if possible it should return by reference:

Typedef!Int x;
x.typedefVal++;

--