December 14, 2016
I really like that solution. +1
December 14, 2016
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 something like Haskells "where" to allow any set of pre-declaration just for one declaration:

with
{
import ...;
alias Result = ...;
}
Result func(blah) {...}
December 14, 2016
On 12/13/16 10:37 PM, Jon Degenhardt wrote:
> I didn't see an example of the syntax when multiple imports are involved
> (apologies if I missed it). Would be good to spell it out.

Thanks for the point and examples, will change the DIP accordingly. -- Andrei
December 14, 2016
On 12/14/16 12:00 AM, Suliman wrote:
> On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>
> Imho such syntaxis construction make language harder to learn. D is
> already pretty complex, but DIPs should simplify language, but do not
> make its harder

Thanks for the input. My take on this is DIPs should make the language _better_. A lot of the time simpler is indeed better, but not always.

The motivation section should cover why we ought to take the hit of a complication in the language. Please let me know where it seems lacking.


Andrei
December 14, 2016
On 12/14/16 2:17 AM, Jacob Carlborg wrote:
> On 2016-12-14 03:23, Andrei Alexandrescu wrote:
>> On 12/13/16 9:22 PM, Hatem Oraby wrote:
>
>>> with(import std.range)
>>> bool equal(R1, R2) if (isInputRange!R1 && isInputRange!R2)
>>> { ... }
>>
>> I considered this, then figured with is superfluous. -- Andrei
>
> It could allow to have a better control of the scope which the import
> affects, i.e.:
>
> with(import std.range)
> {
>   void foo(T) if (isInputRange!T)
>   void bar(T) if (isInputRange!T)
> }

Thanks for this suggestion.

* "with" is superfluous

* The grouping is not indicating that the import is effected only if one of the names is looked up

* I predict 90% of the time there will be one import per declaration, which takes it down to:

with (import std.range)
void foo(T) if (isInputRange!T) {}

which underlines the redundancy of the "with".


Andrei

December 14, 2016
On 12/14/16 3:17 AM, Dicebot wrote:
> On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> Proposed functionality does feel useful but syntax options mentioned in
> the DIP all seem lacking to me. Most importantly, the one suggested as
> primary option puts import after the symbol in lexical order which looks
> baroque and may even be unprecedented in the language (can't think of
> another case like that immediately).

I don't worry about that too much. We have a precedent with names used in the return type of a function, and nobody has ever complained about that:

CommonType!(T1, T2) fun(T1, T2)(T1, T2);


Andrei
December 14, 2016
On 12/14/16 3:43 AM, Yuxuan Shui wrote:
> @import("std.range"):

This seems to break the requirement that declaration-local imports should offer the same amenities as regular imports. It would seem much if we started putting all of the import syntax in strings. -- Andrei
December 14, 2016
On 12/14/16 5:55 AM, pineapple wrote:
> On Wednesday, 14 December 2016 at 01:53:44 UTC, Chris M. wrote:
>> 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)
>> { ... }
>
> On Tuesday, 13 December 2016 at 23:03:39 UTC, Timon Gehr wrote:
>> 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?
>
> I am most in favor of making the function signature either `imports` or
> `@imports`, or doing this:

No inflections please. Walter requires the use of the "import" keyword, and I agree with him.

> struct Buffer(R) if (import std.range:isInputRange!R) { ... }
>
> I also think actually being able to write `alias short = import
> very.long.module_name;` would be great, if only so that the contents of
> a module can be imported into their own user-defined namespace rather
> than the global scope.

The alias fails to meet the DCD principle: the declaration carries dependencies with it.


Andrei

December 14, 2016
On 12/14/16 6:06 AM, rikki cattermole wrote:
> On 14/12/2016 11:33 AM, Andrei Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> Others have brought up similar syntax to this:
>
> import(my.mod).Type!argsT(7)
>
> import(Identifier).Identifier
>
> It shouldn't be confused with string imports or the like and would be
> more akin to a selective import.
>
> Pros:
>  - Is an expression

How does it then apply to declarations? -- Andrei
December 14, 2016
On 12/14/16 7:01 AM, Mathias Lang wrote:
>> Trouble is, there's no real difference between doing that, vs.
>> creating a standalone module containing `foo` and `bar` with `import
>> std.range;` as a top-level import.
>
> That was my impression when reading this DIP. I'm very glad to see that
> decoupling made its way up in the growing list of things to do, my only
> concern is that this syntax sounds like a workaround for giant modules.
>
> Phobos is cited as a motivation for this enhancement. Dare I say that we
> have a problem of modules in phobos being too monolithic, and they
> should be split into more packages, like std.range and std.algorithms did ?

Creating many files indeed works around the problem that dependency granularity is file-level. I don't think that approach is desirable or scalable. -- Andrei