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