On 12/14/16 7:30 AM, ketmar wrote:
> finally, some DIP that addresses something i really think about almost
> every day.

Additional motivating examples are welcome. -- Andrei

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

On Wednesday, 14 December 2016 at 14:19:43 UTC, Andrei Alexandrescu wrote:
> On 12/14/16 7:30 AM, ketmar wrote:
>> finally, some DIP that addresses something i really think about almost
>> every day.
>
> Additional motivating examples are welcome. -- Andrei

it happened that DIP itself has all the samples i can think out. ;-) imports for function arguments and template constraints are the things i want. and i don't really have any favor for any particular syntax.

thanks for making this DIP.

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
> Destroy.

FWIW, the reason why I don't use inline imports in my code:

http://d.puremagic.com/issues/show_bug.cgi?id=7016

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.

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

On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
> Destroy.
>
> https://github.com/dlang/DIPs/pull/51/files
>
>
> Andrei

How about:

bool equal(R1, R2) : std.range
if (isInputRange!R1 && isInputRange!R2)
{ ... }

It's nice and concise, and you could in theory also allow multiple imports with a comma

bool equal(R1, R2) : std.range, std.traits
if (isInputRange!R1 && isInputRange!R2 && isArray!R2)
{ ... }

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?

On Wednesday, 14 December 2016 at 17:01:50 UTC, Andrej Mitrovic wrote:
> On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> How about:
>
> bool equal(R1, R2) : std.range
> if (isInputRange!R1 && isInputRange!R2)
> { ... }
>
> It's nice and concise, and you could in theory also allow multiple imports with a comma
>
> bool equal(R1, R2) : std.range, std.traits
> if (isInputRange!R1 && isInputRange!R2 && isArray!R2)
> { ... }

breaks possible selective import. if both modules exports some symbol, we will need to selectively import and/or rename it.

On Wednesday, 14 December 2016 at 17:09:44 UTC, ketmar wrote:
> On Wednesday, 14 December 2016 at 17:01:50 UTC, Andrej Mitrovic
>>
>> How about:
>>
>> bool equal(R1, R2) : std.range
>> if (isInputRange!R1 && isInputRange!R2)
>> { ... }
>>
>> It's nice and concise, and you could in theory also allow multiple imports with a comma
>>
>> bool equal(R1, R2) : std.range, std.traits
>> if (isInputRange!R1 && isInputRange!R2 && isArray!R2)
>> { ... }
>
> breaks possible selective import. if both modules exports some symbol, we will need to selectively import and/or rename it.

The with keyword then?

bool equal(R1, R2)
with (std.range : isInputRange, isOutputRange) && (std.stdio : writeln) && (std.algorithm)
if (isInputRange!R1 && isInputRange!R2)
{ ... }

A problem with that is that it reads "bool equal with std.stdio if something", suggesting something decides whether or not to import std.stdio.