D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 16180 - Unable to dispose an interface with std.experiment.allocator
Summary: Unable to dispose an interface with std.experiment.allocator
Status: RESOLVED INVALID
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: x86_64 Linux
: P1 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-17 11:55 UTC by Maik Klein
Modified: 2020-03-21 03:56 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Maik Klein 2016-06-17 11:55:35 UTC
I opened a stack overflow question which contains all the needed details 

http://stackoverflow.com/questions/37868594/disposing-a-class-with-an-interface?lq=1
Comment 1 basile-z 2016-06-17 13:51:18 UTC
(In reply to Maik Klein from comment #0)
> I opened a stack overflow question which contains all the needed details 
> 
> http://stackoverflow.com/questions/37868594/disposing-a-class-with-an-
> interface?lq=1

There a dispose overload that works with interface. It's available because you can retrieve the object that implements the interface using "cast(Object) itf".

So to me the report is invalid:

uint a;
interface Bar{}
class Foo: Bar
{
    ~this(){a = 1;}
}

void main()
{
    import std.experimental.allocator.mallocator;
    import std.experimental.allocator;
    auto f = Mallocator.instance.make!Foo();
    Bar b = f;
    Mallocator.instance.dispose(b);
    assert(a == 1);
}

I think that on S.O you ignore what is done here

https://github.com/dlang/phobos/blob/master/std/experimental/allocator/package.d#L1135

This is basically what allows to destroy an object from its interface.
Comment 2 Maik Klein 2016-06-17 14:08:18 UTC
Okay I found the bug. It was using emsi_container as a dependency, even though I did not use it. 

It seems to have a dependency on std.experimental.allocator version 2.70, which then somehow overshadowed the current version of std.experimental.allocator.

And the bug that I am reporting still existed in 2.70 but seems to be fixed in 2.71.

So I guess I maybe should report this as an dub issue?
Comment 3 basile-z 2016-06-17 15:11:56 UTC
I don't know. It's maybe worth asking Hackerpilot if his fork is still needed, the issues are addressed now, almost a year after the pull to phobos.
In emsi containers the submodule allocators is very outdated:

https://github.com/Hackerpilot/experimental_allocator/tree/cd8196a5b063b9019ea5529239da3181cc4fdc4f
Comment 4 Andrei Alexandrescu 2016-06-18 11:18:16 UTC
Looks like we can close this on the stdlib side.