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

[David Gileadi via Digitalmars-d]

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?