On 07/15/2016 10:29 AM, maik klein wrote:
There are two things that bothered me for quite some time

Interior immutability:

Consider a something like this

https://dpaste.dzfl.pl/fa5be84d26bc

The implementation is totally wrong and it doesn't make sense, but it
shows that Rc can not be const/immutable because at least "dup" needs to
increment the counter.

Is it possible to express that Rc should be mutable but the value that
it wraps should be either mutable or const/immutable?

Sure. Just instantiate Rc with a const/immutable T. I.e., write `Rc!(const int)` instead of `const Rc!int`. Or with auto and makeRc: `auto rc = makeRc(immutable int(5));`.

Rvalues and forwarding:

The problem is that when you pass an rvalue to a function you lose the
information that is an rvalue. There is nothing like std::forward from
c++ that I am aware of.

When you pass an rvalue to a function, the parameter inside the function is still an lvalue. The argument being an rvalue just means that you can't pass it in a ref parameter.

That becomes a problem when I use variadics with non copyable types. I
need to call move on types that can not be copied.

Ok, not being copyable is the problem.

I guess what I could do is to use
https://dlang.org/phobos/std_traits.html#hasElaborateCopyConstructor to
detect which types in the variadic args are actually non copyable and
then call .move on them.

Is this how you would do it? The use case would be something like this

void test(Args...)(Args args){
     someOtherTest(args); // doesn't work because args contains some non
copyable types
}

void test(Args...)(Args args){
     someOtherTest(mixin forward!(args));
}

//expands to

void test(Args...)(Args args){
     someOtherTest(args[0].move, args[1], args[2]);
}

If args[0] can be moved, can args[1] and args[2] be moved, too? I mean, can you just move everything without testing for hasElaborateCopyConstructor? Just a thought.

Reply via email to