On Monday, 12 March 2018 at 13:04:54 UTC, Simen Kjærås wrote:
On Monday, 12 March 2018 at 10:37:00 UTC, Alex wrote:
Sure, you have.
https://dlang.org/spec/struct.html#assign-overload
Point #4.
In this case,
ref S opAssign(ref S rhs)
{
return this;
}
True. Can you fix these, too?
struct S {
S* ptr;
this(int dummy) {
ptr = &this;
}
~this() {
assert(ptr == &this);
}
}
void test(S s) {}
unittest {
test(S(0));
}
S test2() {
return S(0);
}
unittest {
S s = test2();
}
ok... this is a little bit more tricky, as there is no assignment
now. :)
But in this two cases I assume, you want to have explicit pass by
reference, no?
struct S {
S* ptr;
this(int dummy) {
ptr = &this;
}
~this() {
assert(ptr == &this);
}
}
void test(ref S s){}
unittest {
auto s = S(0);
test(s);
/*
if I call test(S(0)) with void test(S s) as in your example,
neither the postblit nor opAssign is called... hm... no idea
why...
*/
}
auto test2() {
return new S(0);
}
unittest {
auto s = test2();
/*
This example differs more from the post before :) test2 is a
true factory now,
it has to grant the right setting of all members...
*/
}
Another point is, that I hope, that pointers don't move
anywhere, as in C, by definition.
And why not? D allows for moving garbage collectors.
If it were allowed, then "contiguous memory allocation" for
arrays would be senseless.
unittest {
auto tmp = typeof(S.a)();
}
I thought, this shouldn't be possible (at least in my mind)
It wouldn't, and such code is not possible in D today:
struct S {
int n;
auto a() { return SomeType!(() => n)(); }
}
struct SomeType(alias fn) {
int get() { return fn(); }
}
But this is clearly valid.
Yes, it's an example of code that works in D today, with
similar semantics to those implied in the other example. It's
meant to show that just like `auto tmp = typeof(S.a())()`
doesn't work today, it shouldn't work with the types used in my
other example.
unittest {
// cannot access frame pointer of
foo.S.a.SomeType!(delegate () => this.n).SomeType
auto tmp = typeof(S.a())();
}
For sure, tmp cannot be defined without an instance of S. So
the correct unittest in my eyes would be:
unittest {
S s;
auto res = s.a;
assert(res.get == S.init.n);
}
I think we may be speaking past one another. Yes, your unittest
would be expected to pass.
If we go back to the example code:
struct S1 {
int n, m;
SomeType!(() => n + m) a;
}
vs.
struct S2 {
int n, m;
auto a() { return SomeType!(() => n + m)(); }
}
I would expect typeof(S1.a) and typeof(S2.a()) to be
equivalent. I don't see a good reason why I should be able to
construct an instance of typeof(S1.a), since I can't construct
a typeof(S2.a()).
I see your point that "The latter closures above the current
values inside of [S2]". I'm saying I want the former to do the
same. I understand that it currently doesn't, and I argue that
having it do the same would be a much more useful behavior.
Apart from the fact it's impossible, I don't see any good
reason not to make it work. :p
I see your point too :)
But the latter form just grants the existence of an instance of
S, whereas the first form doesn't.
By the way, this would work:
struct S1 {
static int n, m; // added a static here.
SomeType!(() => n + m) a;
}
struct SomeType(alias fn){}
--
Simen
