On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
> On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad wrote:
>
>>
>> The class reference type should be fixable with a rewrite into templated smart pointers, so no need for big changes there, I think.
>
> Smart pointers impose a specific object lifetime, whereas (D) classes do not. You cannot lower (D) class instances to smart pointers.

Lower? No. Wrap - yes. With "scope" from DIP1000 you can even do it in a safe manner.

On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov wrote:
> But they are incompatible precisely because structs "don't have it". Inheritance for one. Reference semantics for another. A class reference is a pointer in disguise, struct is full layout on the stack. The only way to retain inheritance and reference semantics while removing "class" keyword would be not to merge classes into structs, but structs into classes. And then what, always allocate on the heap?

I don't understand this argument, why would this be more difficult for D than C++?

You lower class into struct (with virtual, interfaces, whistles and bells) and retain reference semantics by making it unavailable for D-move-semantics.

> Which is all possible as a library with zero language changes. But for that to work, classes shall remain classes and structs shall remain structs.

Huh?

> If that were true, we wouldn't even need the "extern(C++)", would we?

Sounds more like an implementation detail to me.

On Saturday, 27 May 2017 at 17:30:49 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov wrote:
>> But they are incompatible precisely because structs "don't have it". Inheritance for one. Reference semantics for another. A class reference is a pointer in disguise, struct is full layout on the stack. The only way to retain inheritance and reference semantics while removing "class" keyword would be not to merge classes into structs, but structs into classes. And then what, always allocate on the heap?
>
> I don't understand this argument, why would this be more difficult for D than C++?

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?

>> Which is all possible as a library with zero language changes. But for that to work, classes shall remain classes and structs shall remain structs.
>
> Huh?

Yes.

>> If that were true, we wouldn't even need the "extern(C++)", would we?
>
> Sounds more like an implementation detail to me.

:) Everything is an "implementation detail".

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?

That is the question.

I am talking about the language, as specified, not the implementation.

> Yes.

Huhhh?? :^)

> :) Everything is an "implementation detail".

No... No... No...

On Saturday, 27 May 2017 at 17:24:14 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
>> On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad wrote:
>>
>>>
>>> The class reference type should be fixable with a rewrite into templated smart pointers, so no need for big changes there, I think.
>>
>> Smart pointers impose a specific object lifetime, whereas (D) classes do not. You cannot lower (D) class instances to smart pointers.
>
> In this context smart pointers are just pointers that aren't raw pointers, e.g. alias this or something.

Then please don't call them "smart", because that term is specifically reserved for something that adds at least some additional features over a regular pointer (bounds checking, memory / lifetime management, etc.).

On Saturday, 27 May 2017 at 17:28:47 UTC, Stanislav Blinov wrote:
> On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
>> On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad wrote:
>>
>>>
>>> The class reference type should be fixable with a rewrite into templated smart pointers, so no need for big changes there, I think.
>>
>> Smart pointers impose a specific object lifetime, whereas (D) classes do not. You cannot lower (D) class instances to smart pointers.
>
> Lower? No. Wrap - yes. With "scope" from DIP1000 you can even do it in a safe manner.

Maybe I was not clear: Of course you can put a class reference inside a struct, or even simulate a class using a rewriting 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.

On Saturday, 27 May 2017 at 18:21:41 UTC, Moritz Maxeiner wrote:
> Then please don't call them "smart", because that term is specifically reserved for something that adds at least some additional features over a regular pointer (bounds checking, memory / lifetime management, etc.).

"smart pointer" just means that it is a pointer wrapped in an ADT. In this context it could provide allocation-information would be one thing it could provide, or reference counting, member access or whatever. The "smart" part was deliberately left unspecified.

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.

I don't recall what the obstacles to getting the monitor changes in where, but I suspect that in order to get them in, someone would effectively have to champion the changes and push them through, and while I think that there was someone trying to do that at one point, they seem to have given up on it. I don't know if they ran into insurmountable problems or simply gave up and left. But as long as D classes have a built-in monitor, then that's one of the key differences between a D class or struct (or a D and C++ class for that matter).

- Jonathan M Davis

On Saturday, 27 May 2017 at 18:33:36 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 18:21:41 UTC, Moritz Maxeiner wrote:
>> Then please don't call them "smart", because that term is specifically reserved for something that adds at least some additional features over a regular pointer (bounds checking, memory / lifetime management, etc.).
>
> "smart pointer" just means that it is a pointer wrapped in an ADT. In this context it could provide allocation-information would be one thing it could provide, or reference counting, member access or whatever. The "smart" part was deliberately left unspecified.

An ADT that adds features to the wrapped pointer; and if it adds features, it is not *just* a normal pointer anymore, i.e. you cannot use it as a verbatim replacement for normal class instances on the language level, because you change their semantics.

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?

You could do this as a compiler configuration even, switch out GC with ref-counting smart pointers.

The point of this thread was to have fewer language constructs, with more lowering, so that the resulting language would be a super-language, that fully covers the original language (or close to it).