On Fri, Jun 20, 2014 at 12:36:53AM +0200, Timon Gehr via Digitalmars-d wrote: > On 06/19/2014 10:29 PM, Dicebot wrote: > >+1 > >I have always wondered why `inout` is limited to const when problem > >is almost identical with all other restrictive attributes. > > I have furthermore always wondered why there can always only be one > `inout' wildcard in scope. This is not the best existing way to solve > this kind of problem: Parametric (i.e. not query-able at either > runtime or compile time inside the function) compile-time arguments do > it better. > > I.e. instead of: > > inout(int)[] foo(inout(int)[] arg){ return arg; } > > do: > > T foo![T <: const(int)[]](T arg){ return arg; } > > this can be extended to other attributes, for example in the following way > (this is just an example): > > void evaluate![transitive_attributes a](void delegate()@a dg)@a{ > dg(); > } [...]
What if there are multiple delegate arguments? void evalTwo(void delegate()@a dg1, void delegate()@b dg2) // how to express union of @a and @b? { dg1(); dg2(); } What if the delegate arguments themselves take delegate arguments? void eval(void delegate(void delegate()@a)@b dg1, void delegate()@c dg2)@d // how to express that @b depends on @a, and // @d depends on @b and @c? { dg1(dg2); } Pretty soon, we need an attribute algebra to express these complicated relationships. It would be nice to have a solution that can handle all of these cases without exploding complexity in the syntax. T -- "The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."