Thread overview
daii - allocator-friendly closures and raii
Jun 23, 2017
Boris-Barboris
Jun 23, 2017
ag0aep6g
Jun 23, 2017
Boris-Barboris
Jul 10, 2017
Martin Nowak
June 23, 2017
Hi, I wrote a small library, inspired by atilaneves automem. I didn't like some things, especially that smart pointers proxied underlying types, also I wanted class upcasting.

https://github.com/Boris-Barboris/daii
https://code.dlang.org/packages/daii

What do you think about the delegate\closure syntax?

https://github.com/Boris-Barboris/daii#delegate

Any ideas and contributions are appreciated.
June 23, 2017
On 06/23/2017 09:02 PM, Boris-Barboris wrote:
> https://github.com/Boris-Barboris/daii

You've got bad `@trusted`s:

https://github.com/Boris-Barboris/daii/blob/3e15429a4000494ce61330fb5adcfc700ec1942c/source/closure.d#L108

`_f` may be unsafe. It can't be trusted.

`args` may have unsafe postblits which may be called when calling `_f`.

--

https://github.com/Boris-Barboris/daii/blob/0e7a3e60f39be48c269826e75bd775b7cfefe51c/source/refcounted.d#L70

`T` may have an unsafe constructor. Can't trust `Allocator.instance.make!(T)`.

Again, `args` may have unsafe postblits.

--

https://github.com/Boris-Barboris/daii/blob/0e7a3e60f39be48c269826e75bd775b7cfefe51c/source/refcounted.d#L105

`T` may have an unsafe destructor. Can't trust `allocator.dispose(ptr)`.

--

https://github.com/Boris-Barboris/daii/blob/3e15429a4000494ce61330fb5adcfc700ec1942c/source/unique.d

Same issues as in refcounted.d.
June 23, 2017
On Friday, 23 June 2017 at 20:13:07 UTC, ag0aep6g wrote:
> You've got bad `@trusted`s:

Ty, I misunderstood the concept. I guess in a code like this it's mostly @system anyways, too many indirections to control safety level. I'm probably gonna remove most of the attributes.
June 23, 2017
On 6/23/17 4:24 PM, Boris-Barboris wrote:
> On Friday, 23 June 2017 at 20:13:07 UTC, ag0aep6g wrote:
>> You've got bad `@trusted`s:
> 
> Ty, I misunderstood the concept. I guess in a code like this it's mostly @system anyways, too many indirections to control safety level. I'm probably gonna remove most of the attributes.

The best advice is to leave @safe and @trusted and @system out of any templates. @safe will be inferred if everything is indeed safe. To prove that it's actually @safe, use a @safe unittest.

For places where things are safe, but the compiler can't prove it, then you pull out the @trusted attribute. But be very very careful -- as ag0aep6g says, there are often many hidden calls that can be @system, and in those cases you have just broken the guarantee. Only use @trusted where you know everything about every type that is used inside the call.

-Steve
July 10, 2017
On 06/23/2017 09:02 PM, Boris-Barboris wrote:
> Hi, I wrote a small library, inspired by atilaneves automem. I didn't like some things, especially that smart pointers proxied underlying types, also I wanted class upcasting.
> 
> https://github.com/Boris-Barboris/daii https://code.dlang.org/packages/daii
> 
> What do you think about the delegate\closure syntax?
> 
> https://github.com/Boris-Barboris/daii#delegate
> 
> Any ideas and contributions are appreciated.

Looks interesting, covariance (upcasting) is definitely a feature
requirement for an standard rc library.
The delegates are interesting. A bit brittle, guess we need some
compiler supported lowering to make non-GC allocated delegates cleaner.

You could try sth. along the lines of

delegate!(sum, "(int v) => sum += v")

but that needs a mixin to rebind the lambda's context.

-Martin