You're right. I didn't read over the OP's example carefully
enough. The
mutation is being done to a module-level variable in an inout
function, which
is completely legit. I thought that what the OP thought was
wrong was mutating
a module-level variable in a non-mutable function (and that's
On Tuesday, 25 June 2013 at 23:39:45 UTC, Ali Çehreli wrote:
With apologies, I have unrelated comments to make.
On 06/25/2013 03:07 PM, Namespace wrote:
this(T x, T y) {
this.x = x;
this.y = y;
points ~= this._point;
I have seen similar designs in the past
On Wednesday, 26 June 2013 at 07:35:08 UTC, Namespace wrote:
On Tuesday, 25 June 2013 at 23:39:45 UTC, Ali Çehreli wrote:
With apologies, I have unrelated comments to make.
On 06/25/2013 03:07 PM, Namespace wrote:
this(T x, T y) {
this.x = x;
this.y = y;
On Wednesday, June 26, 2013 13:16:16 monarch_dodra wrote:
It seems safe, however, your example seems to show how to indeed
break the type system... without a cast (!):
@property
Point* ptr() inout {
points[this.id].x = cast(int) this.x;
points[this.id].y =
On Wednesday, 26 June 2013 at 15:48:42 UTC, Jonathan M Davis
wrote:
It doesn't break anything. It just shows the need for pure.
- Jonathan M Davis
OO I just got it :(
nevermind then...
On Wednesday, 26 June 2013 at 15:48:42 UTC, Jonathan M Davis
wrote:
It doesn't break anything. It just shows the need for pure.
Really? In the following simplified code I see mutation of an
immutable variable, which should not be possible, of course. That
is breaking the type system, no?
On Thursday, June 27, 2013 01:45:22 anonymous wrote:
On Wednesday, 26 June 2013 at 15:48:42 UTC, Jonathan M Davis
wrote:
It doesn't break anything. It just shows the need for pure.
Really? In the following simplified code I see mutation of an
immutable variable, which should not be
On Thursday, 27 June 2013 at 00:53:48 UTC, Jonathan M Davis wrote:
It looks to me like your code is fundamentally different from
the OP's example
rather than being a simplification of the original code. In the
OP's example,
the variable being mutated is a module-level variable, so the
On Thursday, June 27, 2013 03:31:01 anonymous wrote:
On Thursday, 27 June 2013 at 00:53:48 UTC, Jonathan M Davis wrote:
It looks to me like your code is fundamentally different from
the OP's example
rather than being a simplification of the original code. In the
OP's example,
the
I want to ask if this code should compile or if it's a bug,
because I circumvent the const system:
import std.stdio;
struct Point {
int x, y;
}
Point*[] points;
struct TplPoint(T) {
public:
Point _point;
T x, y;
const uint id;
this(T x, T y) {
On Wed, 26 Jun 2013 00:07:38 +0200, Namespace rswhi...@googlemail.com
wrote:
I want to ask if this code should compile or if it's a bug, because I
circumvent the const system:
import std.stdio;
struct Point {
int x, y;
}
Point*[] points;
struct TplPoint(T) {
public:
On Wednesday, June 26, 2013 00:07:38 Namespace wrote:
I want to ask if this code should compile or if it's a bug,
because I circumvent the const system:
import std.stdio;
struct Point {
int x, y;
}
Point*[] points;
struct TplPoint(T) {
public:
Point _point;
T x, y;
If you change uint to size_t it works fine AFAIK.
On Wednesday, June 26, 2013 00:52:58 Namespace wrote:
If you change uint to size_t it works fine AFAIK.
Yes. It's easy enough to fix, but it _is_ arguably a bug in the code, and it's
the only one that's obvious to me. I don't understand what about the code
makes you think that it might be
With apologies, I have unrelated comments to make.
On 06/25/2013 03:07 PM, Namespace wrote:
this(T x, T y) {
this.x = x;
this.y = y;
points ~= this._point;
I have seen similar designs in the past where constructors had
side-effects such as registering the
15 matches
Mail list logo
