nothrow function callbacks in extern(C) code - solution

[H. S. Teoh via Digitalmars-d]

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