struct A
{
void f()
{
SecBuffer b;
b.clear(); //fail
}
private:
import core.sys.windows.sspi;
static void clear(ref SecBuffer sb)
{
sb.BufferType=SECBUFFER_EMPTY;
}
}
alias clear=A.clear;
It is undesirable to declare extension methods at global scope if they use local imports.
Comment #1 by schveiguy — 2017-10-17T18:48:17Z
Only non-member functions can be UFCS. I don't think this is going to change.
This really is solved with the proposed "Self important" imports. See here: http://forum.dlang.org/post/[email protected]
Which also dip 1005 was aimed to solve, but not sure that is moving forward.
Comment #2 by dfj1esp02 — 2017-10-19T15:08:02Z
This destroys encapsulation: what has no business at global scope shouldn't be there.
Comment #3 by schveiguy — 2017-10-19T15:26:22Z
You have a choice, make your extension methods global, or don't use UFCS to call them:
clear(b);
This is a perfectly reasonable tradeoff. D usually frowns upon having the same code mean different things in different contexts. UFCS already pushes that envelope, we don't need to push it more.
Comment #4 by dfj1esp02 — 2017-10-20T16:18:48Z
(In reply to Steven Schveighoffer from comment #3)
> make your extension methods global
This destroys encapsulation: what has no business at global scope shouldn't be there.
> D usually frowns upon having the
> same code mean different things in different contexts.
This is not the case for UFCS.
Comment #5 by schveiguy — 2017-10-20T17:21:57Z
(In reply to anonymous4 from comment #4)
> (In reply to Steven Schveighoffer from comment #3)
> > make your extension methods global
>
> This destroys encapsulation: what has no business at global scope shouldn't
> be there.
Using clear(b) does not destroy encapsulation.
>
> > D usually frowns upon having the
> > same code mean different things in different contexts.
>
> This is not the case for UFCS.
Correct, it is not because local functions do not supersede global ones for UFCS.
void foo(int) {}
void main()
{
void foo(int) {}
1.foo; // calls global foo
}