Attribute transference from callbacks?

[Timon Gehr]

On 12/8/24 20:19, Steven Schveighoffer wrote:
> On Sunday, 8 December 2024 at 05:54:40 UTC, Manu wrote:
>> I've been trying out an API strategy to use sink functions a lot more 
>> to hoist the item allocation/management logic to the user and out from 
>> the work routines. This idea has received a lot of attention, and I 
>> heard a lot of people saying this was a planned direction to move in 
>> phobos and friends.
>>
>> ```d
>> void parseThings(string s, void delegate(Thing) sink)
>> {
>>   //...
>>   sink(Thing());
>>   //...
>> }
>> ```
>>
>> We have a serious problem though; a function that receives a sink 
>> function
>> must transfer the attributes from the sink function to itself, and we 
>> have
>> no language to do that...
>> What are the leading strategies that have been discussed to date? Is 
>> there
>> a general 'plan'?
> 
> I've proposed something like the following in the past, but I don't know 
> how much appetite there is for it:
> 
> ```d
> // assuming Thing() is @nogc nothrow @safe, but not pure
> void parseThings(string s, @called void delegate(Thing) sink) @nogc 
> nothrow @safe
> {
>     sink(Thing());
> }
> ```
> ...

Well, this is more sane than the "contract invalidation" proposal in 
that it is explicit, does not change the meaning of existing code, and 
allows somewhat more composition patterns. It's also forward-compatible 
with a proper solution, while most likely remaining more convenient for 
the cases where it is sufficient.

So maybe it's worth pursuing to stop some of the bleeding, but this will 
run into its own limitations very quickly.

In terms of implementation, it's probably a bit tricky to catch every 
place where the compiler assumes that e.g. `@safe` actually means 
`@safe`. And there are also traits like `isSafe` that would most likely 
subtly change meaning.