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

[Timothee Cour via Digitalmars-d]

one more thing:

we can simplify further (while still having formatted looking code) with
!q{} instead of !() :

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

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

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

// can specify other dependencies beyond imports and have arbitrary complex
logic:
@deps!q{
  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!q{import std.algorithm;};

@deps1
void test4(){}
```



On Thu, Dec 15, 2016 at 3:46 PM, ArturG via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Thursday, 15 December 2016 at 19:52:50 UTC, Andrei Alexandrescu wrote:
>
>> On 12/15/2016 02:22 PM, Timothee Cour via Digitalmars-d wrote:
>>
>>> Some more details on my proposa based on UDA:
>>>
>>> ...
>>>
>>> I now understand the idea, thank you.
>>
>> My question is, doesn't this take things too far? Earlier I wrote:
>>
>> The acceptability of the proposal decays exponentially with its
>>> deviation from existing import syntax.
>>>
>>
>> Indeed adding less syntax is better, but that's not an absolute; the
>> optimum isn't necessarily at the "zero syntax added" point. This is because
>> there are several things to harmonize in language design, which naturally
>> are in tension.
>>
>>
>> Andrei
>>
>
> Something like Timothee Cour's @deps proposal is interesting,
> because it adds the same options to DCD's as module level imports have.
>
> They can be applied to any symbol that supports udas which the current
> syntax from the dip doesnt.
>
> As he displayed, they can be used to group symbols together which makes it
> more dry, but that can also be a drawback when refactoring depending which
> version you use.
>
> And you dont have to support all shown features as that syntax is easier
> extendable.
>
> The initial version could support only import statements.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20161215/2692f98a/attachment-0001.html>