Destroy.

https://github.com/dlang/DIPs/pull/51/files


Andrei

(eh I was off by one zero in the title)

On 12/13/2016 05:33 PM, Andrei Alexandrescu wrote:
> Destroy.
>
> https://github.com/dlang/DIPs/pull/51/files

The "View" mode offers formatting before merging: https://github.com/andralex/DIPs/blob/10ca2e22c0d759c81e4b3afbdc085d7131f68b85/DIPs/DIP1005.md -- Andrei

On 13.12.2016 23:33, Andrei Alexandrescu wrote:
> Destroy.
>
> https://github.com/dlang/DIPs/pull/51/files
>
>
> Andrei

1. The syntax is ambiguous.

Is import.foo.bar.baz the symbol baz in module foo.bar, or the symbol bar.baz in module foo?

I'd prefer syntax like (import foo.bar).baz and (import foo).bar.baz. (I.e., the syntax of import expressions would closely mirror that of import declarations, and would be unambiguous.)

2. The behaviour of aliases to import expressions should be defined explicitly.

I.e.

alias short = import very.long.module_name;

void foo(int i)(short.T a){ ... }

does this import the module if foo is not instantiated?

On 12/13/16 6:03 PM, Timon Gehr wrote:
> On 13.12.2016 23:33, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> 1. The syntax is ambiguous.
>
> Is import.foo.bar.baz the symbol baz in module foo.bar, or the symbol
> bar.baz in module foo?
>
> I'd prefer syntax like (import foo.bar).baz and (import foo).bar.baz.
> (I.e., the syntax of import expressions would closely mirror that of
> import declarations, and would be unambiguous.)

That is a problem. I switched to the most attractive alternate syntax. https://github.com/andralex/DIPs/blob/2e5859c0f64ac4949123fe8de39ccf2ccf72d859/DIPs/DIP1005.md


Andrei

On 14.12.2016 01:14, Andrei Alexandrescu wrote:
> On 12/13/16 6:03 PM, Timon Gehr wrote:
>> On 13.12.2016 23:33, Andrei Alexandrescu wrote:
>>> Destroy.
>>>
>>> https://github.com/dlang/DIPs/pull/51/files
>>>
>>>
>>> Andrei
>>
>> 1. The syntax is ambiguous.
>>
>> Is import.foo.bar.baz the symbol baz in module foo.bar, or the symbol
>> bar.baz in module foo?
>>
>> I'd prefer syntax like (import foo.bar).baz and (import foo).bar.baz.
>> (I.e., the syntax of import expressions would closely mirror that of
>> import declarations, and would be unambiguous.)
>
> That is a problem. I switched to the most attractive alternate syntax.
> https://github.com/andralex/DIPs/blob/2e5859c0f64ac4949123fe8de39ccf2ccf72d859/DIPs/DIP1005.md
>
>
>
> Andrei
>

I'd still advise to match the syntax of other import declarations. What justifies the difference? (Note that import(foo.bar.baz) is a string import.)

On Wednesday, 14 December 2016 at 00:21:23 UTC, Timon Gehr wrote:
> On 14.12.2016 01:14, Andrei Alexandrescu wrote:
>> On 12/13/16 6:03 PM, Timon Gehr wrote:
>>> [...]
>>
>> That is a problem. I switched to the most attractive alternate syntax.
>> https://github.com/andralex/DIPs/blob/2e5859c0f64ac4949123fe8de39ccf2ccf72d859/DIPs/DIP1005.md
>>
>>
>>
>> Andrei
>>
>
> I'd still advise to match the syntax of other import declarations. What justifies the difference? (Note that import(foo.bar.baz) is a string import.)

Maybe it's a good idea to make it a property?

e.g.:

@import("std.stdio") void process(File f);

On Tuesday, 13 December 2016 at 23:03:39 UTC, Timon Gehr wrote:
> On 13.12.2016 23:33, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> 1. The syntax is ambiguous.
>
> Is import.foo.bar.baz the symbol baz in module foo.bar, or the symbol bar.baz in module foo?
>
> I'd prefer syntax like (import foo.bar).baz and (import foo).bar.baz. (I.e., the syntax of import expressions would closely mirror that of import declarations, and would be unambiguous.)
>

Why not something like import foo.bar : baz or import foo : bar.baz to distinguish between module and symbol? It's already used anyway.

Also I like Yuxuan's idea, the other ideas seem to add more clutter after the function name

On 12/13/16 8:07 PM, Chris M. wrote:
>
> Why not something like import foo.bar : baz or import foo : bar.baz to
> distinguish between module and symbol? It's already used anyway.
>
> Also I like Yuxuan's idea, the other ideas seem to add more clutter
> after the function name

So we have:

// 1
struct Buffer(R) if ((import std.range).isInputRange!R) { ... }

// 2
struct Buffer(R) if (import std.range:isInputRange!R) { ... }

// 3
@import("std.stdio") struct Buffer(R) if (isInputRange!R) { ... }

The first two require repeating the import for each separate declaration, e.g.:

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

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

The last is surprising because it uses a string where otherwise there would be an unquoted list of dot-separated names.

I prefer the current form of the proposal:

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

The point has been brought up that the syntax import(std.range) is also used for string imports. It is a drawback.


Andrei

On Wednesday, 14 December 2016 at 01:39:01 UTC, Andrei Alexandrescu wrote:

> I prefer the current form of the proposal:
>
> bool equal(R1, R2)
> import (std.range)
> if (isInputRange!R1 && isInputRange!R2)
> { ... }
>
> The point has been brought up that the syntax import(std.range) is also used for string imports. It is a drawback.
>
>
> Andrei

How about using "imports" instead of "import"? Simple enough change, and it still makes sense

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