On 12/14/16 9:27 AM, Andrei Alexandrescu wrote:
On 12/14/2016 11:02 AM, default0 wrote:
On Wednesday, 14 December 2016 at 14:21:55 UTC, Andrei Alexandrescu
wrote:
On 12/14/16 8:26 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the
declaration, so
that the symbols imported can be used in the declaration?
Thanks. I considered this but it put pressure on the relationship
between the name and where it's looked up. Consider that imports in a
function don't need to be at the top. They may also be in nested
scopes inside the function. It becomes quite tenuous to explain where
the parameter type names are looked up. -- Andrei
Could restrict to imports that come before any other statements in the
function body, ie:
// valid, compiles when instantiated
void fun(Range)(Range r) if(isInputRange!Range) {
import std.range;
}
// invalid, import is not picked up because it is not the first
statement in the method body
void fun(Range)(Range r) if(isInputRange!Range) {
doThings();
import std.range;
}
If this is desirable, the error message for failed symbol lookup of
symbols in a function declaration should hint that imports in the
function body are only considered if they stand at the beginning of the
function, to help mitigate confusion.
Seems simple enough to specify and explain, honestly.
To me it seems like adding additional rules to make up for a weakness
that should be avoided in the first place. -- Andrei
For the little that it's worth, my opinion is that it's easier to
understand/teach the proposed rule above than the new syntax in DIP1005.
This is true for me whether the proposed rule applies to all imports
within the top scope of the template function/class/struct, or only to
imports at the beginning of that scope.
The above rule doesn't cover non-template function declarations like the
`process` example in the DIP, however. Are they an important enough use
case to justify new syntax?
