On 27 May 2017 at 20:34, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, May 27, 2017 16:37:04 Ola Fosheim Grøstad via Digitalmars-d wrote:
>> > Monitor (i.e. for "synchronized") and
>>
>> Wasn't this going to be removed?
>
> There was definitely talk of doing it, but it's never actually happened. I don't think that it was actually decided that we would though, and some other things that we _definitely_ decided we do have never actually happened either (e.g. remove delete from the language and remove toString, toHash, opCmp, and opEquals from Object). Getting major changes in is often something that doesn't work out very well given the obstacles involved.
>

There's nothing blocking the deprecation of monitors.  Just someone needs to do the work.

On Sunday, 28 May 2017 at 08:24:50 UTC, Iain Buclaw wrote:
> Strictly speaking, this already is the case.
>
>     Something sth = new Something (...);
>
> all that is really doing is just:
>
>     struct Something* sth = new Something (...);
>
> You just aren't exposed this in the language.

Right, but since the language now is more powerful than it was in D1, it should be possible to implement class references as a templated struct, right? So there is no longer a need for this special casing of class vs struct.

The only thing you need to do is modify "new" to recognize it. I think?

On 27 May 2017 at 20:13, Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 27 May 2017 at 18:06:11 UTC, Stanislav Blinov wrote:
>>
>> Perhaps it wouldn't be if we were talking about new language.
>> With D, such a change falls out of "some language changes, a bit of
>> automated source updating and a little bit of breakage", and becomes "whole
>> language change, a rewrite of runtime and standard library, and breaking
>> every single project that uses D today".
>> Or did we leave behind your original question?
>
>
> No. I am talking about language semantics. Are the semantics for class and struct conflicting or can they be merged?
>

The semantic difference is that structs are POD records, and classes
are references (or pointers) to GC heap with inheritance (underlying
record includes fields from base classes).

For ABI, structs are compatible with C (this is documented as per
spec), and classes underlying records are compatible with C++ (don't
think this is documented, but it's certainly assumed).

Focusing on the latter point, this means that the following declarations:

    struct Something
    {
        int a;
        long b;
        char c;
    }

    class Something
    {
        int a;
        long b;
        char c;
    }

are identical to each other, apart from the latter getting a __vptr and __monitor field.

However, for extern(D) classes, there's actually nothing stopping a D compiler implementer from making class types more memory efficient, an optimizing compiler could decide to re-arrange class fields as:

    class Something
    {
        long b;
        int a;
        char c;
    }

After all, we only need extern(D) to be compatible with ourselves, not
other languages.

As a side note, when I talked about D at the GNU Hackers Meeting a number of years back, when I said that structs and classes are two distinct types - one being POD-only, the other being a reference that comes with the bells and whistles of OOP - I actually got a small cheer.  This gives me a very strong impression of what C++ programmers think of their own situation regarding struct vs class, and that we should not be so eager to follow their design.

On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
> However, for extern(D) classes, there's actually nothing stopping a D compiler implementer from making class types more memory efficient, an optimizing compiler could decide to re-arrange class fields as:
>
>     class Something
>     {
>         long b;
>         int a;
>         char c;
>     }

Yes, but you could do that for structs as well, after static analysis establishing that it no code in this specific program is making assumptions about layout.

Or you could have an attribute that says that that field X should be at byte-offset N, but all other fields can move.

> As a side note, when I talked about D at the GNU Hackers Meeting a number of years back, when I said that structs and classes are two distinct types - one being POD-only, the other being a reference that comes with the bells and whistles of OOP - I actually got a small cheer.  This gives me a very strong impression of what C++ programmers think of their own situation regarding struct vs class, and that we should not be so eager to follow their design.

Did they explain why? Many other languages provide a single construct with far more wide-ranging features than D/C++.

For generic programming it is generally better to have fewer constructs, but you might need a way convenient way to express constraints (i.e. C++ concepts).

On 28 May 2017 at 13:30, Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
>>
>> However, for extern(D) classes, there's actually nothing stopping a D compiler implementer from making class types more memory efficient, an optimizing compiler could decide to re-arrange class fields as:
>>
>>     class Something
>>     {
>>         long b;
>>         int a;
>>         char c;
>>     }
>
>
> Yes, but you could do that for structs as well, after static analysis establishing that it no code in this specific program is making assumptions about layout.
>
> Or you could have an attribute that says that that field X should be at byte-offset N, but all other fields can move.
>
>> As a side note, when I talked about D at the GNU Hackers Meeting a number of years back, when I said that structs and classes are two distinct types - one being POD-only, the other being a reference that comes with the bells and whistles of OOP - I actually got a small cheer.  This gives me a very strong impression of what C++ programmers think of their own situation regarding struct vs class, and that we should not be so eager to follow their design.
>
>
> Did they explain why? Many other languages provide a single construct with far more wide-ranging features than D/C++.
>

I said it all in one breath, so you could leave it up to interpretation whether they applauded the fact that there is a separation in semantics, or whether there is no multiple inheritance in D (except via interfaces).

When asking one person over dinner later about what they felt was wrong about struct/class in C++, I got the impression that because there's almost no distinction between the two, class seems more like a misfeature of C++.  You could say that C++ should have stuck to one type, instead of having two.  And because in D we make a very clear distinction, that justifies the reason to have both struct and class.

On Sunday, 28 May 2017 at 12:31:35 UTC, Iain Buclaw wrote:
> I said it all in one breath, so you could leave it up to interpretation whether they applauded the fact that there is a separation in semantics, or whether there is no multiple inheritance in D (except via interfaces).
>
> When asking one person over dinner later about what they felt was wrong about struct/class in C++, I got the impression that because there's almost no distinction between the two, class seems more like a misfeature of C++.

Well, class and struct is semantically the same in C++. The only difference is that you don't have private and protected on structs. So the distinction is historical, to quote cppreference.com: «The keywords are identical except for the default member access and the default base class access.»

> You could say that C++ should have stuck to one type, instead of having two.

Struct and class is one type in C++. The difference is in the syntax where the grammar does not allow access protection for the struct keyword. So not semantical, but syntactical.

> And because in D we make a very clear distinction, that justifies the reason to have both struct and class.

But you don't make a very clear distinction in D.  If struct was a pure value type and mapped to pure valued tuples, then you might have a justification for it. From a type-system point of view the distinction makes no sense to me.

On Sunday, 28 May 2017 at 14:30:00 UTC, Ola Fosheim Grøstad wrote:
> Struct and class is one type in C++. The difference is in the syntax where the grammar does not allow access protection for the struct keyword. So not semantical, but syntactical.

I.e. you can just search-and-replace "struct" with "class" in C++ and it will behave the same way.

"struct" is only used as a mnemonic device...