Thread overview | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 19, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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? -- |
April 19, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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); -- |
April 19, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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. -- |
April 19, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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 :-) -- |
April 19, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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. -- |
April 22, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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. -- |
April 22, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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. -- |
April 22, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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. -- |
April 24, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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. -- |
April 24, 2014 [Issue 12597] Payload getter for std.typecons.Typedef | ||||
---|---|---|---|---|
| ||||
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++; -- |
Copyright © 1999-2021 by the D Language Foundation