UCFS does not work for nested functions?

[Steven Schveighoffer]

On 6/18/18 2:57 PM, Bastiaan Veelo wrote:
> 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.
>>
> 
> I don't understand. What local symbol would be overwritten by which 
> module-level symbol?

In other words, if UFCS meant that module-level symbols took precedent 
over local symbols, then it's backwards in terms of which place usually 
wins. Generally it's the local symbols.

> 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;
> }
> ```

It's a good question, I don't think it has a particularly satisfying 
answer. But one thing I will note, is that this is valid today:

void bar(int) {writeln("module");}

void main() {
      static void bar(int) {writeln("local");}
      int x;
      x.bar; // "module"
}

Adding UFCS support to locals, which one would be the expected call? 
It's difficult to imagine the local being the lower priority, but it 
would have to be that way to avoid code breakage.

-Steve