Bug 13579 – Add limitations to Uniform Function Call Syntax

I don't yet have much personal experience writing D code but I have a strong suspicion that "extension methods" are superior to UFCS. First I want to note that the Dr. Dobb's UFCS article (http://www.drdobbs.com/blogs/cpp/232700394) describes extension methods incorrectly. Extension methods can be called with infix notation or with function notation; marking a method as an extension method only increases the ways it can be used. 1. UFCS is not self-documenting. I assume that in most use cases, a function is intended either to be called as a function, or to be called via UFCS. D doesn't give us a way to express this intention. 2. As a result of #1, UFCS will pollute auto-complete lists and similar tools. Tools will probably end up needing to add tool-specific ways to mark up UFCS functions. 3. I think UFCS has pitfalls similar to C++'s conversion constructors, except D doesn't even have the "explicit" keyword to opt out of it and it's not limited to single-parameter functions. If breaking backward compatibility is at all an option, I suggest requiring functions to opt in to UFCS syntax in some way. Probably by adding an attribute. If someone wants to use UFCS on a function that doesn't allow it, they might be allowed to declare an identical function with the attribute added which forwards the call. A template or keyword could automate this. Perhaps when old-style UFCS is deprecated a DMD flag could be added that automatically generates source files with the attribute added to functions with UFCS usage. If it's too late to fix it or opt-in is undesirable, I suggest something like C++'s "explicit" keyword which allows us to disable UFCS for specific functions. I was unable to find any good pre-existing discussion on these problems but please close this Issue without warning if it has already been thoroughly considered.

Language design issues are best discussed in the newsgroups/forums.

> I don't yet have much personal experience writing D code Well then, let's change the language and break all code while your seat hasn't even gotten warm yet.

(In reply to Andrej Mitrovic from comment #2) > Well then, let's change the language and break all code while your seat > hasn't even gotten warm yet. ad hominem...

(In reply to Vladimir Panteleev from comment #1) > Language design issues are best discussed in the newsgroups/forums. Yes, I suggest to open a discussion thread in the main D newsgroup, and show bug-prone examples, and some syntax and/or semantics to reduce such supposed source of bugs.

Sorry, I don't personally have time for such a demanding discussion. (And I don't have any examples right now, other than this old thing http://redd.it/vvpfy) Please don't hesitate to start such a thread in my place if you want or just close/ignore this issue.

Potentially moved already into forums as a Language Design Issue.