On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote:
On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lo
On Friday, 1 February 2019 at 23:24:44 UTC, Olivier FAURE wrote:
At no point is the compiler aware that the user intends for x
to be interpreted as a getter.
In theory, at least, that's what @property is for.
On Friday, 1 February 2019 at 09:10:15 UTC, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lowered to
something else:
The thing is, D doesn't really differe
On Thursday, 31 January 2019 at 21:50:32 UTC, Steven
Schveighoffer wrote:
How is the problem not in doubleMyValue? It's sole purpose is
to update an lvalue. It is the perfect candidate to mark with
@disable for rvalues.
But right now, updating an rvalue is what ref is supposed to be
used for.
On Thursday, 31 January 2019 at 21:57:21 UTC, Steven
Schveighoffer wrote:
That being said, you can look at the fact that most people
don't even know about this problem, even seasoned veterans, as
a sign that it's really not a big problem.
Isn't it a recurring theme on this forum that D is real
On Tuesday, 29 January 2019 at 10:00:22 UTC, zoujiaqing wrote:
The HuntLabs team is happy to announce the release of Hunt
Framework 2.0.
Is there an online comparison describing the differences between
Hunt and Vibe.d? I'm mainly interested in
- fast incremental compilation,
- high run-time
On Friday, 1 February 2019 at 15:58:50 UTC, Aliak wrote:
On Friday, 1 February 2019 at 14:41:52 UTC, 12345swordy wrote:
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
[...]
http://wilzbach.github.io/d-dip/DIP24
I'm not sure your rewrite is good
On Friday, 1 February 2019 at 14:41:52 UTC, 12345swordy wrote:
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
[...]
http://wilzbach.github.io/d-dip/DIP24
I'm not sure your rewrite is good though, because it does not
preserve aliasing during the
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lowered to
something else
On Friday, 1 February 2019 at 12:51:18 UTC, Atila Neves wrote:
[snip]
I appreciate the reply. Thanks.
On Friday, 1 February 2019 at 11:48:51 UTC, Timon Gehr wrote:
On 01.02.19 10:10, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a
getter? For it not to be a compile error pt.x should also have
a setter, in which case the code needs to be lowered to
something else
On Thursday, 31 January 2019 at 16:01:33 UTC, jmh530 wrote:
On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote:
[snip]
I've never had a need to use complicated values, so I haven't
coded that.
If presented with an example, I think there's a high chance
I'd consider it an anti-p
On 01.02.19 10:10, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a getter?
For it not to be a compile error pt.x should also have a setter, in
which case the code needs to be lowered to something else:
{
auto __temp = pt.x;
doubleMyValue(__temp);
pt.x =
On Thursday, 31 January 2019 at 21:50:32 UTC, Steven
Schveighoffer wrote:
On 1/31/19 4:46 PM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 18:31:22 UTC, Steven
Schveighoffer wrote:
BTW, the DIP discusses how to annotate these rare situations:
int doubleMyValue(ref int x) { ... }
@disab
On Friday, 1 February 2019 at 07:43:23 UTC, Petar Kirov
[ZombineDev] wrote:
So, assuming you have the MSVC C++ toolchain installed, just
build with dub by specifying either the --arch=x86_mscoff or
--arch=x86_64 flags.
But no one should ever need to modify their dmd installation,
in order to us
15 matches
Mail list logo
