nothrow function callbacks in extern(C) code - solution

Artur Skawina via Digitalmars-d digitalmars-d at puremagic.com
Fri Jun 20 04:57:36 PDT 2014


On 06/20/14 01:39, H. S. Teoh via Digitalmars-d wrote:
> 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:
>>> 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

>> 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?

> What if the delegate arguments themselves take delegate arguments?

> Pretty soon, we need an attribute algebra to express these complicated
> relationships.

Simple propagation, from just one source, would be enough for almost all
cases - there's no need to over-complicate this. The remaining cases could
be handled via introspection and ctfe; this way allows for more options,
not just using some pre-defined algebra subset, which happens to be
supported by a particular compiler (-version).

> It would be nice to have a solution that can handle all of these cases
> without exploding complexity in the syntax.

Actually supporting parametrized attributes, is something that I think
everybody agrees on in principle (hence the lack of discussions when
this topic is mentioned, every few weeks or so). The required semantics
are pretty clear; what I still haven't seen is a good enough syntax
proposal. One syntax that might have worked for built-in attributes 
could have been "const!A" etc, but I'm not sure if the parameter
inference would be intuitive enough, and it would appear, at least
superficially, to  potentially clash with user defined attributes,
especially once those become more powerful.

artur


More information about the Digitalmars-d mailing list