UCFS does not work for nested functions?

Steven Schveighoffer schveiguy at yahoo.com
Mon Jun 18 17:58:11 UTC 2018


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


More information about the Digitalmars-d-learn mailing list