On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad wrote:

>> 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?
>
> That is the question.
>
> I am talking about the language, as specified, not the implementation.

Ahem. As specified, classes are reference types, struct aren't. What more is there to say?

On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov wrote:
> On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad wrote:
>
>>> 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?
>>
>> That is the question.
>>
>> I am talking about the language, as specified, not the implementation.
>
> Ahem. As specified, classes are reference types, struct aren't. What more is there to say?

Structs are reference types too. The specification is wrong.

On Saturday, 27 May 2017 at 18:44:42 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov wrote:
>> On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad wrote:
>>
>>>> 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?
>>>
>>> That is the question.
>>>
>>> I am talking about the language, as specified, not the implementation.
>>
>> Ahem. As specified, classes are reference types, struct aren't. What more is there to say?
>
> Structs are reference types too. The specification is wrong.

I've seen this argument from you before, and it's incorrect. Structs may adopt reference semantics if they aggregate pointers, that's true. But they are not themselves reference types. Their representation is laid out inline. Classes, OTOH, are always references, to get at their memory you need an indirection. Thus, if we were to merge classes and structs, we'd have to pick one or the other.

On Saturday, 27 May 2017 at 18:42:02 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 18:26:07 UTC, Moritz Maxeiner wrote:
>> mechanism, but you *cannot*  use a smart pointer as a replacement for a class instance, because the latter is normal pointer, and the former adds features on top of a pointer; they cannot be the same as a matter of definition, i.e. you cannot replace classes with smart pointer structs on the language level, because it removes features from the language.
>
> I am not sure what you mean here. As long as the "smart pointer" is in a subtype relationship with the current "class reference" then it can add features, yes?

An example, then:

---
module a;
class Foo {}

module b;
import a;
void bar(Foo foo) {}
---

Here, `bar`, takes a (pointer to a) class instance as parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS, with *no* special semantics.
You cannot replace the meaning of type `Foo` here with something that is not also exactly 8 bytes (on 64bit OS) with no special semantics, because that changes the semantics of `bar`. i.e. `Foo` must not be a smart pointer because a smart pointer necessarily introduces features (and thus changes the semantics).
And this is exactly what you were proposing in the sentence I replied to; you were proposing to essentially change the semantics of every use of a class instance in all D code by rewriting `Foo` into a smart pointer.

>
> The point of this thread was to have fewer language constructs,

And my reply was "if you want to do this, it must use a normal pointer, not a smart pointer, because that changes semantics". If you want a smart pointer, use one, but don't suddenly make something that isn't a smart pointer by language design change shape into a smart pointer.

> with more lowering, so that the resulting language would be a super-language, that fully covers the original language (or close to it).

Sure, but then type `Foo` in the above must remain a normal pointer, not become a smart pointer.

On Saturday, 27 May 2017 at 18:56:47 UTC, Stanislav Blinov wrote:
> I've seen this argument from you before, and it's incorrect. Structs may adopt reference semantics if they aggregate pointers, that's true. But they are not themselves reference types. Their representation is laid out inline.

This is the ACID test: Values have no identity. An instance of a struct has an identity.

Allocation is another issue. A stack allocation is just an optimization of a heap allocation. Many languages put all the activation records (stack frames) on the heap. This is very useful for high levels of concurrency.

> Classes, OTOH, are always references, to get at their memory you need an indirection. Thus, if we were to merge classes and structs, we'd have to pick one or the other.

Structs are more general, so you don't have to pick anything, you just add the class features to the struct.

That means the minimal core language no longer have the class concept.

The full language with lowering (syntactical sugar) still has the class concept since it can be covered by struct + "smart pointer" + modified new.

On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
> Here, `bar`, takes a (pointer to a) class instance as parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS, with *no* special semantics.

Does the language spec say anything about the size of class references?

> If you want a smart pointer, use one, but don't suddenly make something that isn't a smart pointer by language design change shape into a smart pointer.

Is it specified?

The common implementation uses a GC, but does it say that an implementation cannot use a reference counted smart pointer or a fat pointer instead?

> Sure, but then type `Foo` in the above must remain a normal pointer, not become a smart pointer.

That really depends on the definition of the language.

On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
>> Here, `bar`, takes a (pointer to a) class instance as parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS, with *no* special semantics.
>
> Does the language spec say anything about the size of class references?

Yes, is is defined as `ptrsize` and must have the exact same size as a pointer to a struct and - more importantly - a pointer to a stack frame[1].

>
>> If you want a smart pointer, use one, but don't suddenly make something that isn't a smart pointer by language design change shape into a smart pointer.
>
> Is it specified?

Yes, see above link. Unless you make *all* stack frame pointers smart pointers (which makes no sense whatsoever), class instances cannot be smart pointers in the language as it is specified right now.

>
> The common implementation uses a GC, but does it say that an implementation cannot use a reference counted smart pointer or a fat pointer instead?
>
>> Sure, but then type `Foo` in the above must remain a normal pointer, not become a smart pointer.
>
> That really depends on the definition of the language.

Sure, and the definition requires it.

[1] https://dlang.org/spec/abi.html#delegates

On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote:
> On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
>>> Here, `bar`, takes a (pointer to a) class instance as parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS, with *no* special semantics.
>>
>> Does the language spec say anything about the size of class references?
>
> Yes, is is defined as `ptrsize` and must have the exact same size as a pointer to a struct and - more importantly - a pointer to a stack frame[1].

Huh? You are talking about lambdas?

Didnt find anything on class references in that Intel specific ABI, which appears to be optional anyway.


> Yes, see above link. Unless you make *all* stack frame pointers smart pointers (which makes no sense whatsoever), class instances cannot be smart pointers in the language as it is specified right now.

I don't understand. Why are frame pointers relevant for class references?



> Sure, and the definition requires it.

Why?

On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote:
>
> Sure, and the definition requires it.
>
> [1] https://dlang.org/spec/abi.html#delegates

Please note that an ABI is an implementation specific linkage detail, it cannot be portable so it does not define language semantics.

On 27 May 2017 at 16:12, Ola Fosheim Grøstad via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> I wonder, what would break if all the features of class was merged into struct?
>
> Imagine that:
>
>     class Something ... { ... }
>
> is lowered into:
>
>     struct _class_Something ... { ... }
>     alias Something = MagicClassRef!_class_Something;
>
> Is it conceivable with some language changes, a bit of automated source updating and a little bit of breakage?
>

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.