On Thursday, 27 February 2014 at 13:31:45 UTC, Dicebot wrote:
> On Thursday, 27 February 2014 at 13:18:51 UTC, Remo wrote:
>> Then the question is why not use structs all the time?
>
> Key class feature is run-time polymorphism (via interfaces/inheritance). I tend to use structs for everything else in my personal code.

That is very similar to my thoughts atm. Explicit call to init() / terminate() are so C :/ It really seems that there is no escape from value semantics and shared_ptr. Worst part is there is no even standard shared/weak pointer provided. I must say I am kindof disappointed by all this. I realize that it is not D's fault but still, it is suppose to be "better C++", and while I do see that wrt to templates / TMP, my favourite feature of C++ are d-tors...

On Thursday, 27 February 2014 at 14:29:05 UTC, Szymon Gatner wrote:
> Explicit call to init() / terminate() are so C :/

It is much better than C because of `scope(exit) terminate()` though :)
Also you can use struct destructors same as in C++

> Worst part is there is no even standard shared/weak pointer provided.

There is http://dlang.org/phobos/std_typecons.html#.RefCounted which helps in some cases.

> I must say I am kindof disappointed by all this. I realize that it is not D's fault but still, it is suppose to be "better C++", and while I do see that wrt to templates / TMP, my favourite feature of C++ are d-tors...

It is not supposed to be "better C++", not anymore at least. Something that dissapoints lot of people and there has been a lot of pushing in this direction lately but historically this domain was under-developed.

On Thursday, 27 February 2014 at 14:18:47 UTC, Dicebot wrote:
> On Thursday, 27 February 2014 at 14:14:43 UTC, Namespace wrote:
>> Why not? Overhead? No RAII support?
>
> Simply no reason to use classes, structs have all features I need for cases when polymorphism is not necessary (95%+). Being value type is also convenient as it leaves more control to the programmer and RAII is nice cherry on top.

They actually don't have all the necessary features in D afaiu. They do have value semantics but can't represent uniqueness because of missing move d-tor.

For example in C++ I can create a function that returns a Texture class instance and be sure that it is the only one when receiving it (because copying is disabled). Then I can always safely release all resources related to this texture in objects d-tor. In D I can't use struct for this because I would get double-free in d-tor so a class instance has to be used instead.

On Thursday, 27 February 2014 at 14:37:14 UTC, Szymon Gatner wrote:
> They actually don't have all the necessary features in D afaiu. They do have value semantics but can't represent uniqueness because of missing move d-tor.
>
> For example in C++ I can create a function that returns a Texture class instance and be sure that it is the only one when receiving it (because copying is disabled). Then I can always safely release all resources related to this texture in objects d-tor. In D I can't use struct for this because I would get double-free in d-tor so a class instance has to be used instead.

You can disable postblit to make entity non-copyable: http://dlang.org/struct.html#StructPostblit

There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)

Priceless for message passing concurrency.

On Thursday, 27 February 2014 at 14:41:27 UTC, Dicebot wrote:
> On Thursday, 27 February 2014 at 14:37:14 UTC, Szymon Gatner wrote:
>> They actually don't have all the necessary features in D afaiu. They do have value semantics but can't represent uniqueness because of missing move d-tor.
>>
>> For example in C++ I can create a function that returns a Texture class instance and be sure that it is the only one when receiving it (because copying is disabled). Then I can always safely release all resources related to this texture in objects d-tor. In D I can't use struct for this because I would get double-free in d-tor so a class instance has to be used instead.
>
> You can disable postblit to make entity non-copyable: http://dlang.org/struct.html#StructPostblit

How can I then use it as a function return value? Or store in a container?

Actually if postblit had a bool param saying that the source is rvalue then moving would be possible by just resetting relevant fields in source object.

On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
> There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)
>
> Priceless for message passing concurrency.

Tbh it only looks worse and worse to me :(

Another example of code necessary to overcome language limitations.

On Thursday, 27 February 2014 at 14:52:00 UTC, Szymon Gatner wrote:
> On Thursday, 27 February 2014 at 14:42:43 UTC, Dicebot wrote:
>> There is also one complex and feature-reach implementation of uniqueness concept by Sonke Ludwig : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d#L281 (Isolated!T)
>>
>> Priceless for message passing concurrency.
>
> Tbh it only looks worse and worse to me :(
>
> Another example of code necessary to overcome language limitations.

Do you know Rust? http://www.rust-lang.org/

Szymon Gatner:

> Tbh it only looks worse and worse to me :(

Perhaps for your use case it's better for you to stick with C++11? While I have written a good amount of D code (perhaps 200_000 lines or more), I still use Python a lot, etc.

Bye,
bearophile

On Thursday, 27 February 2014 at 14:49:48 UTC, Szymon Gatner wrote:
>> You can disable postblit to make entity non-copyable: http://dlang.org/struct.html#StructPostblit
>
> How can I then use it as a function return value? Or store in a container?
>
> Actually if postblit had a bool param saying that the source is rvalue then moving would be possible by just resetting relevant fields in source object.

Yep, moving ownership is the main issue (as opposed to just prohibiting any copy). But returning from function is not copying because of D semantics and you can do some tricks because of it:

http://dpaste.dzfl.pl/99ca668a1a8d

==================================

import std.c.stdlib;

struct Unique
{
	int* data;
	
	@disable this(this);
	
	~this()
	{
		if (data)
			free(data);
	}
	
	Unique release()
	{
		scope(exit) this.data = null;
		return Unique(data);
	}
}

void main()
{
	Unique x1 = Unique(cast(int*) malloc(int.sizeof));
	
	// auto x2 = x1; // error
	auto x2 = x1.release();
	assert(x1.data is null);
	assert(x2.data !is null);
}