On 2015-02-28 06:57, deadalnix wrote:

> I think this is justified to break the code here, but I share the
> irritation in front of the inconsistency.

I don't think so because it's so easy to making it a non-breaking change, i.e. require a compiler recognized UDA to enable the functionality.

-- 
/Jacob Carlborg

On 2015-02-28 10:41, Paolo Invernizzi wrote:

> I agree, as, well, this is starting to look pretty grotesque...
>
> The druntime/phobos 2.067 are breaking every piece of software out there
> that relies on core.sync or concurrency.scheduler, vibe and tango included.

Add DWT to that list.

-- 
/Jacob Carlborg

On 2015-02-27 21:04, Andrei Alexandrescu wrote:

> I'm fine with breaking code of people who happen to use the names
> opAddRef and opRelease. -- Andrei

I don't think so because it's so easy to making it a non-breaking change, i.e. require a compiler recognized UDA to enable the functionality.

-- 
/Jacob Carlborg

On 28 February 2015 at 02:02, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/27/15 7:52 AM, Manu via Digitalmars-d wrote:
>>
>> Can I call opAddRef/opRelease from within the postblit/destructor
>> manually and expect the compiler to elide calls correctly?
>> That doesn't seem foolproof though, and you also said manual calls are
>> not @safe. Why not specify a call sequence?
>
>
> Ah, I think you mean structs that have a class member? The compiler will insert opAddRef and opRelease appropriately:

Well, not specifically. I mean any struct that has any indirect member(/s).
The point of a struct is that the layout is entirely at user
discretion, and I may want to pass some small RC aggregate by value.

I'd like to see a struct with RC operators have implicit calls
generated (and elided) for exactly the same set of cases as classes,
in terms of construction/destruction/assignment/passing to/from
functions.
It's at my discretion what the contents of my struct is (in most of my
cases, just pointers to opaque types, but not classes).

If that's not practical (for instance, because classes assign by reference, but struc opAssign may do anything), then we should be able to call inc/dec ref manually, and have them optimise correctly? But that sounds like much more trouble to me.

> =========
> * struct, class, and closure types that have RCO members accommodate calls
> to opRelease during their destruction.
> =========
>
>
> Andrei
>

On 28 February 2015 at 02:00, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/27/15 7:52 AM, Manu via Digitalmars-d wrote:
>>
>> Well this is the case of the highest value to me, and DIP74 offers nothing?
>
>
> For structs you use postblit and destructors. -- Andrei

That doesn't work now, and I don't see why that would suddenly work under DIP74?

On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
> On 28 February 2015 at 02:00, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 2/27/15 7:52 AM, Manu via Digitalmars-d wrote:
>>>
>>> Well this is the case of the highest value to me, and DIP74 offers
>>> nothing?
>>
>>
>> For structs you use postblit and destructors. -- Andrei
>
> That doesn't work now, and I don't see why that would suddenly work under DIP74?

Per DIP25 and RCSlice, you may define a safe struct with reference counting that owns resources. -- Andrei

On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
> I'd like to see a struct with RC operators have implicit calls
> generated (and elided) for exactly the same set of cases as classes,
> in terms of construction/destruction/assignment/passing to/from
> functions.

The short answer is that probably won't happen. -- Andrei

On 1 March 2015 at 12:21, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
>>
>> I'd like to see a struct with RC operators have implicit calls generated (and elided) for exactly the same set of cases as classes, in terms of construction/destruction/assignment/passing to/from functions.
>
>
> The short answer is that probably won't happen. -- Andrei

*sigh* ... ever, or in DIP74?

I presented my 80% case to you before. I just want this to work efficiently:

extern(C) void inc(void*);
extern(C) void dec(void*);

struct X
{
  void *thing;

  opInc() { inc(thing); }
  opDec() { dec(thing); }
}


X is a struct, not a class.
If DIP74 can't do this efficiently, then it's no use to me.


Do I need to abuse the type system by declaring:
class Opaque
{
  void opInc() { inc(cast(void*)this); }
  void opDec() { dec(cast(void*)this); }
}

That's a really lame thing to do. Debuggers will dereference Y, try and present a vtable and stuff to me. In the event I want to mirror the opaque C struct definition on the D side, I can't express it because class has implicit members which aren't actually there.

What is the resistance to making it work on struct? It just seems like another arbitrary edge case in the language.

On 2/28/15 6:49 PM, Manu via Digitalmars-d wrote:
> On 1 March 2015 at 12:21, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
>>>
>>> I'd like to see a struct with RC operators have implicit calls
>>> generated (and elided) for exactly the same set of cases as classes,
>>> in terms of construction/destruction/assignment/passing to/from
>>> functions.
>>
>>
>> The short answer is that probably won't happen. -- Andrei
>
> *sigh* ... ever, or in DIP74?

In the foreseeable future.

> I presented my 80% case to you before. I just want this to work efficiently:
>
> extern(C) void inc(void*);
> extern(C) void dec(void*);
>
> struct X
> {
>    void *thing;
>
>    opInc() { inc(thing); }
>    opDec() { dec(thing); }
> }

struct X
{
  void *thing;

  this(this) { inc(thing); }
  ~this() { dec(thing); }
}


Andrei

On 1 March 2015 at 12:51, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/28/15 6:49 PM, Manu via Digitalmars-d wrote:
>>
>> On 1 March 2015 at 12:21, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
>>>>
>>>>
>>>> I'd like to see a struct with RC operators have implicit calls generated (and elided) for exactly the same set of cases as classes, in terms of construction/destruction/assignment/passing to/from functions.
>>>
>>>
>>>
>>> The short answer is that probably won't happen. -- Andrei
>>
>>
>> *sigh* ... ever, or in DIP74?
>
>
> In the foreseeable future.
>
>> I presented my 80% case to you before. I just want this to work efficiently:
>>
>> extern(C) void inc(void*);
>> extern(C) void dec(void*);
>>
>> struct X
>> {
>>    void *thing;
>>
>>    opInc() { inc(thing); }
>>    opDec() { dec(thing); }
>> }
>
>
> struct X
> {
>   void *thing;
>
>   this(this) { inc(thing); }
>   ~this() { dec(thing); }
> }

You've conveniently ignored the word 'efficient'.
Okay, so if I'm not better off then I've always been, what is the good
of DIP74 to me?