DIP10005: Dependency-Carrying Declarations is now available for community feedback

[deadalnix via Digitalmars-d]

On Thursday, 15 December 2016 at 03:26:24 UTC, Meta wrote:
> On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei 
> Alexandrescu wrote:
>> Destroy.
>>
>> https://github.com/dlang/DIPs/pull/51/files
>>
>>
>> Andrei
>
> What's the main goal with this proposal? Is it to introduce 
> DCDs into the language or is it to clean up some warts of the 
> local import pattern, i.e.:
>
> int doSomething(T)(T t) //std.range is lazily imported but
> {                       //can't be used in the signature
>     import std.range;
>     //...
> }
>
> struct Test(R) //Ditto
> {
>     import std.algorithm;
>     //etc...
> }
>
> I'm assuming it's the former, or there wouldn't be any talk 
> about introducing any new syntax. Imports would just be made 
> completely lazy and we wouldn't have to change the language at 
> all otherwise. So other than the fact that you can move the 
> declaration anywhere without breaking it due to missing 
> imports, are the advantages that DCDs provide really worth it 
> enough to introduce yet another clause that can be put on any 
> declaration? Especially when we have another solution (lazy 
> imports) that does exactly what you want but excludes the DCD 
> aspect?

I think there is a case to be made to use the import in the 
symbol's signature, which is currently not possible. Not sure it 
pays for itself to add a feature in the language just for this.

The tooling case is moot IMO. The languages keeps being fubared 
with obtuse complexities, which makes tooling harder to write, 
and then this is used an an excuse to fubar it even more. This 
isn't leading to a good place.

Now there are some ways I see this happen leveraging the 'with' 
creating a "with import" construct.

void foo(R)(R r) if (isInputRange!R) with import std.range {
     // ...
}

The good thing here is that the import syntax doesn't need to be 
altered in any way. You can still do "with import foo.bar : buzz".