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
perf
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,
> >
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
immutabil
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 b
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? What
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, 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 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;
>
> p
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
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
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 viol
If you change uint to size_t it works fine AFAIK.
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;
>
On Wed, 26 Jun 2013 00:07:38 +0200, 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;
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) {
15 matches
Mail list logo
