DIP10005: Dependency-Carrying Declarations is now available for community feedback

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 14 08:27:34 PST 2016


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


More information about the Digitalmars-d mailing list