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
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;
}
On Monday, 12 March 2018 at 09:54:20 UTC, Simen Kjærås wrote:
But I don't have a hook to update the pointer when the struct
is moved. The GC may move my struct without informing me in any
way. In fact, even just a copy construction will break this:
struct S {
S* ptr;
this(int dummy)
On Monday, 12 March 2018 at 08:59:49 UTC, Alex wrote:
An incomplete type is perfectly ok, so there should be no
problem with a pointer of the same type inside a struct.
If accidentally the pointer refers "this", then it must have
been set after construction. As before construction the value
of
On Monday, 12 March 2018 at 07:04:19 UTC, Simen Kjærås wrote:
On Saturday, 10 March 2018 at 17:43:06 UTC, Simen Kjærås wrote:
I'm not sure how fixable this is, but I am sure that there's
plenty of benefit to being able to write code like this:
struct S {
int n, m;
SomeType!(() => n + m
On Saturday, 10 March 2018 at 17:43:06 UTC, Simen Kjærås wrote:
I'm not sure how fixable this is, but I am sure that there's
plenty of benefit to being able to write code like this:
struct S {
int n, m;
SomeType!(() => n + m) a;
}
over this:
struct S {
int n, m;
auto a() { ret
On Friday, 9 March 2018 at 23:34:56 UTC, Mike Franklin wrote:
On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:
1) Wrong return type:
unittest {
S s;
auto a = s.field;
// Fails - typeof(a) is Property!((get) => this.n, (set)
=> this.n = set)
assert(is(typeof(a) == in
On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:
This is the best I've come up with in the current language:
struct S {
int n;
mixin property!("field", "get => this.n", "set => this.n =
set");
}
Not bad. Not good, but not bad either.
Sadly, there are issues:
1) Wrong
On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote:
* binary assignment operators (e.g. +=)
* unary assignment operators (e.g. ++)
* @safe, @nogc, and -betterC compatible
* at least as good code generation as that proposed in the DIP
when optimizations are enabled.
* And should be scal
On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote:
I would like to know if this can be improved to support the
following:
* binary assignment operators (e.g. +=)
* unary assignment operators (e.g. ++)
* @safe, @nogc, and -betterC compatible
* at least as good code generation as that
On Tuesday, 20 February 2018 at 14:34:53 UTC, bauss wrote:
Would there be a reason why this wouldn't be a good
implementation?
If so what and how could it be improved?
Are there flaws in an implementation like this?
[... snip ...]
I am very interested in this as a potential alternative to th
On Tuesday, 20 February 2018 at 14:34:53 UTC, bauss wrote:
Would there be a reason why this wouldn't be a good
implementation?
What is the intended use case for this? The main feature seems to
be an ability to have read-only members, which is nice. Are there
other benefits?
If so what and
Would there be a reason why this wouldn't be a good
implementation?
If so what and how could it be improved?
Are there flaws in an implementation like this?
struct Property(T, bool readOnly = false)
{
import std.traits : isScalarType, isArray,
isAssociativeArray, isSomeString;
priva
13 matches
Mail list logo
