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@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.