December 13, 2016 DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei |
December 13, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | (eh I was off by one zero in the title) |
December 13, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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?
|
December 13, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 |
December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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.)
|
December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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);
|
December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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
|
December 13, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris M. | 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
|
December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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)
{ ... }
|
Copyright © 1999-2021 by the D Language Foundation