December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dominikus Dittes Scherkl | I really like that solution. +1 |
December 14, 2016 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jon Degenhardt | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yuxuan Shui | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to pineapple | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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 Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mathias Lang | 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
|
Copyright © 1999-2021 by the D Language Foundation