April 03, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 --- Comment #10 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-04-02 17:27:02 PDT --- > Do you want to explain why? > (Constructors are functions, so why introduce an asymmetry.) In great part because they're _not_ normal functions. They're constructors. They're also not free functions, and the whole idea with UFCS was that it would work with free functions so that you could act like the function was a member of the type of its first argument. It allowed you to essentially add member functions to a type, and therefore be able to not care whether a function was implemented on a type or as a free function, thereby making code more generic. This is trying to take UFCS beyond free functions, and it makes no sense for a constructor to be treated as a member function of another type, because it never could have been implemented as a member function of that type in the first place. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
April 03, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 Maxim Fomin <maxim@maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxim@maxim-fomin.ru --- Comment #11 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-04-02 19:24:36 PDT --- (In reply to comment #7) > I really wish people who implement language features spent 10 minutes of their time writing documentation about it. As it stands, it seems only compiler hackers seem to know what language features actually exist and are expected to work. This is a good description of how D project is organized, I often face some strange behavior of dmd and such idea comes to my mind. Regarding issue - I think that it moves UFCS beyond its purpose and looks like extending UFCS for operator overloaded function which I consider a bad idea. Better option I think is to move discussion to forum or to write a DIP which has recommended itself as a structured process of proposing. Bugzilla and github discussions are not suitable for significant language changes (do you remember threads about alias T = A syntax after semi-silent depreciation in git pull?). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
April 03, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 --- Comment #12 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-04-02 23:15:54 PDT --- (In reply to comment #8) > Some tried to claim that TDPL said that it was in the language, but > all TDPL ever talked about was arrays, because that's all that there was and > all that was planned for. The only reason that it was ever expanded beyond > arrays was because people kept asking for it. That's complete BS. Read the fine-print, it clearly says on page 156: "If a.fun(b, c, d) is seen but fun is not a member of a's type, D rewrites that as fun(a, b, c, d) and tries that as well." It doesn't matter that the page talked about arrays beforehand. It says right there "a's type", it doesn't say "array type". But note that it also says: "The opposite path is never taken: if you write fun(a, b, c, d) and it does not work, a.fun(b, c, d) is not tried" So this could be interpreted against this enhancement request, although TDPL has been made wrong before.. > But it _has_ been months (probably over a > year now, though I'm not sure) The oldest changelog entry I can find about UFCS is for version 2.055, which was released Sep 4 2011, and this is for a bug that was filed March 03 2011. And the oldest UFCS bug was filed in 2006: Issue 662 We've had UFCS for years. It's been a feature years in the making, it should have documentation by now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
April 08, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 --- Comment #13 from bearophile_hugs@eml.cc 2013-04-08 16:49:59 PDT --- (In reply to comment #11) > Better option I think is to move discussion to forum or to write a DIP OK: http://forum.dlang.org/thread/mxsipaadpufujicmerjn@forum.dlang.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
July 02, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 --- Comment #14 from bearophile_hugs@eml.cc 2013-07-02 04:27:25 PDT --- For potential downsides see also: http://forum.dlang.org/thread/sdffgyosxmfjjjrshajy@forum.dlang.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
July 03, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 timon.gehr@gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timon.gehr@gmx.ch --- Comment #15 from timon.gehr@gmx.ch 2013-07-03 09:05:16 PDT --- The discussion is misguided. opCall is compatible with UFCS already. I suggest to close this down and to open a more detailed enhancement request for using local symbols with UFCS instead if that is desired. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
July 03, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 bearophile_hugs@eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #16 from bearophile_hugs@eml.cc 2013-07-03 09:42:17 PDT --- (In reply to comment #15) > The discussion is misguided. opCall is compatible with UFCS already. Right, I didn't realize this works: struct Foo { int opCall(bool b) { return 0; } } Foo foo; void main() { auto b1 = foo(true); // OK auto b2 = true.foo; // Error } > I suggest to close this down OK, closed. > and to open a more detailed enhancement request for using local symbols with UFCS instead if that is desired. That's a quite different need. It needs more thinking. Thank you for the note. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
July 06, 2013 [Issue 9857] UFCS for struct opCall | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile_hugs@eml.cc | http://d.puremagic.com/issues/show_bug.cgi?id=9857 --- Comment #17 from Kenji Hara <k.hara.pg@gmail.com> 2013-07-06 02:29:24 PDT --- (In reply to comment #16) > > and to open a more detailed enhancement request for using local symbols with UFCS instead if that is desired. > > That's a quite different need. It needs more thinking. Thank you for the note. UFCS is designed not work for local symbols. https://github.com/D-Programming-Language/dlang.org/pull/346 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation