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

[Timothee Cour via Digitalmars-d]

Some more details on my proposa based on UDA:

// applies to next decl
@deps!({import std.algorithm;})
void test1(){}

// applies to a set of decls
@deps!({import std.stdio;}){
  void test2(){}
  void test3(){}
}

// applies to all following decls (':')
@deps!({import std.array;}):

// can specify other dependencies beyond imports and have arbitrary complex
logic:
@deps!({
  import std.range;
  static int[100] data2;
  version(linux){
    enum data1=import("foo");//string import
    pragma(lib, "curl");
  }
}):
void test4(){}

// Can alias some dependencies:
alias deps1=deps!({import std.algorithm;});

@deps1
void test4(){}

NOTE: the above code compiles if we add
`struct deps(T...){}`, but that logic would be implemented in the compiler.

Advantages:

* no new syntax (just new semantics)
* no nesting inside {} required, so no additional indentation
* allows grouping multiple declarations under a single set of imports
* `grep import` will still work unlike many of the existing proposals
* can use existing traits to query for such imports (eg getSymbolsByUDA)
* allows a more general solution (eg also handles `pragma(lib, "curl");` if
we want that as well)

(Note: ignore the `variant 2` i had described above)

On Thu, Dec 15, 2016 at 8:32 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 12/15/2016 11:11 AM, Walter Bright wrote:
>
>> On 12/15/2016 6:53 AM, Andrei Alexandrescu wrote:
>>
>>> The document does specify the advantages and disadvantages of lazy
>>> imports, as follows:
>>>
>>> ===
>>> * Full lazy `import`s. Assume all `import`s are lazy without any
>>> change in the
>>> language. That would allow an idiom by which libraries use fully
>>> qualified names
>>> everywhere, and the `import`s would be effected only when names are
>>> looked up.
>>> This would allow scalability but not the dependency-carrying aspect.
>>> ===
>>>
>>
>> That would be a massive breaking change.
>>
>
> This may be a misunderstanding. The idiom would be opt-in so existing
> behavior will be preserved (albeit it won't benefit of the improvements).
>
> Andrei
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20161215/ff7915f1/attachment-0001.html>