Today I hit two problems essentially which got me thinking about how structs are used in D by most of the code I've seen so far. Both problems are in:

http://d.puremagic.com/issues/show_bug.cgi?id=9513

So the RedBlackTree create excessive copies of large structs via binaryFun, that and the obvious workaround also necessitates use of a template. It seems that people use structs to indicate one of two things, they want a type they can pass around and return by copy such as vectors/matrices etc. or just a way to allocate something on the stack, usually because of the need for deterministic resource handling or for performance reasons.

One of the great things about the D is that it allows you to specify with the type how it should be used by choosing struct vs class, so you can say at the same time whether the data should be stored on the heap and whether it should be passed by copy or by reference.

It seems to me that it might nice also to have a sub-division within the "struct" to allow the user to indicate a struct that should be passed by reference also like a class. It could be the same in every way except it's always passed by reference and people would have to write their own dup or something for when they want to copy it.

This could also solve the problem of:

    functionWithRefParams(LargeStruct.init, LargeStruct.init)

These new structs would always be passed by reference, and I guess lvalues would be transformed to temporary stack objects by the compiler so that they never have to be copied. To me the "scope ref" proposal looks a bit like C++ rvalue references and I thought this might be simpler and more useful but I don't know it's probably not a good idea.

On Sunday, 23 February 2014 at 14:36:36 UTC, Arlon Brandy wrote:
> Today I hit two problems essentially which got me thinking about how structs are used in D by most of the code I've seen so far. Both problems are in:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9513
>
> So the RedBlackTree create excessive copies of large structs via binaryFun, that and the obvious workaround also necessitates use of a template. It seems that people use structs to indicate one of two things, they want a type they can pass around and return by copy such as vectors/matrices etc. or just a way to allocate something on the stack, usually because of the need for deterministic resource handling or for performance reasons.
>
> One of the great things about the D is that it allows you to specify with the type how it should be used by choosing struct vs class, so you can say at the same time whether the data should be stored on the heap and whether it should be passed by copy or by reference.
>
> It seems to me that it might nice also to have a sub-division within the "struct" to allow the user to indicate a struct that should be passed by reference also like a class. It could be the same in every way except it's always passed by reference and people would have to write their own dup or something for when they want to copy it.
>
> This could also solve the problem of:
>
>     functionWithRefParams(LargeStruct.init, LargeStruct.init)
>
> These new structs would always be passed by reference, and I guess lvalues would be transformed to temporary stack objects by the compiler so that they never have to be copied. To me the "scope ref" proposal looks a bit like C++ rvalue references and I thought this might be simpler and more useful but I don't know it's probably not a good idea.

There is also a work around (I can't remember who posted it originally) but to move a struct to heap its basically:

struct T {}
T t;
T* ptrT = [t].ptr;