On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer
wrote:
On 6/18/18 1:25 PM, bauss wrote:
On Monday, 18 June 2018 at 17:16:29 UTC, aliak wrote:
On Monday, 18 June 2018 at 14:19:30 UTC, Steven Schveighoffer
wrote:
On 6/18/18 7:16 AM, Bastiaan Veelo wrote:
On Sunday, 18 May 2014 at 08:15:08 UTC, Steffen Wenz wrote:
Hi,
Just noticed that using UFCS does not work for nested
functions, and was wondering whether that's intended, and
what the rationale behind it is:
I just had the same question.
I can imagine that the context pointer of nested functions
complicates things, but making `bar` `static` does not
help. Has anything changed in recent years regarding the
difficulty of implementing UFCS for nested functions? Would
it be easier to only support static nested functions?
```
void main() {
static void bar(int x) {}
int x;
x.bar(); // Error: no property 'bar' for type 'int'
}
```
It's never been supported, and likely will not be. I think
the idea is that you can override expected behavior inside
by accidentally defining some function locally with the same
name.
Wondering how this is different than with non-nested
functions? If a global function has the same name as a member
function then the member function takes precedence. So
wouldn't the same thing just apply here if it were supported?
I second this.
What then can happen is that your local calls can get hijacked
from outside the module, if someone happens to define something
later that you happened to import. D tries to avoid such
possibilities.
There's not much precedent for local symbols being overridden
by module-level symbols.
-Steve
I don't understand. What local symbol would be overwritten by
which module-level symbol?
Whatever the concerns, what is the difference regarding these
concerns between this:
```
// Valid today
void bar(int) {}
void main() {
int x;
b.bar;
}
```
and this:
```
\\ Invalid today
void main() {
static void bar(int) {}
int x;
x.bar;
}
```
