On Monday, 18 June 2018 at 19:26:47 UTC, Steven Schveighoffer
wrote:
On 6/18/18 2:58 PM, aliak wrote:
[...]
It's the same in the fact that your call is silently switched
to a different call. However, in the current syntax, an
external entity CANNOT override a local function. When you call
t
On Monday, 18 June 2018 at 19:31:39 UTC, Steven Schveighoffer
wrote:
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.
Ah, you mean it would have to be that way
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, Bastia
On 6/18/18 2:58 PM, aliak wrote:
On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer wrote:
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 possibili
On Monday, 18 June 2018 at 17:58:11 UTC, Steven Schveighoffer
wrote:
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 preceden
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
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 d
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
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
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 ima
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 fun
Steffen Wenz:
Just noticed that using UFCS does not work for nested functions,
Right.
and was wondering whether that's intended, and what the
rationale behind it is:
Currently it's intended. Because doing otherwise causes other
problems with struct/class member functions. Perhaps there a
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:
class X {
void foo() {}
}
void main() {
// moving bar to module scope solves the error below
void bar(X x) {}
13 matches
Mail list logo
