Re: ref for (const) variables
On Tuesday, 17 March 2015 at 18:14:48 UTC, Jonathan M Davis wrote: How long is the ref returned by getFoo even valid? Maybe it refers to memory that gets freed on the next line. The compiler can't know. The problem is not specific to variables, any reference type has that issue.
Re: ref for (const) variables
On Monday, March 16, 2015 18:46:59 Namespace via Digitalmars-d-learn wrote: May this be worth of an enhancement request? Or was this already rejected? And, no, I want no mutable references such as C++. Walter has been adamantly against having ref variables like C++ has. They're a potential @safety issue and add a fair bit of complication to the language. I doubt that suggesting that we have them as const-only would change his mind any - especially since that addresses none of the @safety issues. - Jonathan M Davis
Re: ref for (const) variables
On Tuesday, 17 March 2015 at 09:56:09 UTC, Jonathan M Davis wrote: On Monday, March 16, 2015 18:46:59 Namespace via Digitalmars-d-learn wrote: May this be worth of an enhancement request? Or was this already rejected? And, no, I want no mutable references such as C++. Walter has been adamantly against having ref variables like C++ has. They're a potential @safety issue and add a fair bit of complication to the language. I doubt that suggesting that we have them as const-only would change his mind any - especially since that addresses none of the @safety issues. - Jonathan M Davis If I can't mutate them, where are the @safety issues?
Re: ref for (const) variables
On 03/17/2015 11:14 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
Or, take this example which (unfortunately) currently compiles:
ref int getBar(ref int bar) @safe
{
return bar;
}
ref int getFoo() @safe
{
int foo;
return getBar(foo);
}
void main()
{
getFoo() = 7;
}
[...]
I believe that the return attribute stuff that was recently added is
intended to solve these issues
Yes, it is available on git head (and works without @safe):
ref int getBar(return ref int bar) @safe// -- Add 'return'
{
return bar;
}
ref int getFoo() @safe
{
int foo;
return getBar(foo);// -- Does not compile anymore
}
so I'm not very familiar with the details.
I think there are corner cases that even the 'return' attribute does not
solve but I did not follow those discussions.
Ali
Re: ref for (const) variables
On Tuesday, March 17, 2015 09:59:59 Namespace via Digitalmars-d-learn wrote:
On Tuesday, 17 March 2015 at 09:56:09 UTC, Jonathan M Davis wrote:
On Monday, March 16, 2015 18:46:59 Namespace via
Digitalmars-d-learn wrote:
May this be worth of an enhancement request? Or was this
already
rejected?
And, no, I want no mutable references such as C++.
Walter has been adamantly against having ref variables like C++
has. They're
a potential @safety issue and add a fair bit of complication to
the
language. I doubt that suggesting that we have them as
const-only would
change his mind any - especially since that addresses none of
the @safety
issues.
- Jonathan M Davis
If I can't mutate them, where are the @safety issues?
With regards to what they refer to. For instance,
ref const(Foo) getFoo();
ref const(Foo) foo = getFoo();
How long is the ref returned by getFoo even valid? Maybe it refers to memory
that gets freed on the next line. The compiler can't know. So, foo may or
may not stay valid, and so it's not @safe unless the compiler can guarantee
the lifetime of what foo refers to.
Or, take this example which (unfortunately) currently compiles:
ref int getBar(ref int bar) @safe
{
return bar;
}
ref int getFoo() @safe
{
int foo;
return getBar(foo);
}
void main()
{
getFoo() = 7;
}
By the time getFoo returns, what it's returning is already invalid. So, the
code _isn't_ @safe, even though the compiler claims it is. Allowing
something like
void main()
{
ref const(int) foo = getFoo();
}
would just perpetuate the problem. What foo refers to is _already_ invalid
even without having to worry about whether it will stay valid when the code
after it does whatever it does.
I believe that the return attribute stuff that was recently added is
intended to solve these issues, but I haven't really looked at it much yet,
so I'm not very familiar with the details. And maybe those changes would
make it so that allowing ref variables would work. I don't know. But const
really isn't the issue. It's lifetime. It has to be guaranteed that what the
ref refers to is valid for at least as long as the ref is.
- Jonathan M Davis
Re: ref for (const) variables
On Monday, 16 March 2015 at 19:20:09 UTC, anonymous wrote: On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. It is, for example, not nullable. ;) Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed. I will research this. Thank you.
ref for (const) variables
Currently, if you want to store a long getter into a variable
without copying it (because it may be a big struct), your only
way is to store it as a pointer:
struct Matrix {
float[16] values= [
1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1
];
}
struct Test {
private:
Matrix _matrix;
public:
ref const(Matrix) getCurrentModelViewMatrix() const pure
nothrow {
return _matrix;
}
}
void main() {
Test t;
const(Matrix)* m = t.getCurrentModelViewMatrix(); //
currently
}
But IMO it would be a lot nicer if I could store the reference
like this:
ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer
[Of course the name is exaggerated for the purpose of
demonstration.]
May this be worth of an enhancement request? Or was this already
rejected?
And, no, I want no mutable references such as C++.
Re: ref for (const) variables
On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed.
Re: ref for (const) variables
On Monday, 16 March 2015 at 19:20:09 UTC, anonymous wrote: On Monday, 16 March 2015 at 18:47:00 UTC, Namespace wrote: const(Matrix)* m = t.getCurrentModelViewMatrix(); // currently } But IMO it would be a lot nicer if I could store the reference like this: ref const(Matrix) m = t.getCurrentModelViewMatrix(); // nicer [Of course the name is exaggerated for the purpose of demonstration.] May this be worth of an enhancement request? Maybe, but I think you'd have to present a better argument. It's not obvious to me how `ref T x = y;` is supposed to be a lot nicer than `T* x = y;`. Or was this already rejected? I don't know. But since it's a C++ thing, it's probably been discussed. The last time we discussed about scope, Walter suggested allowing `ref` for local variables. He might not be opposed to extend it further to members. On the other hand, `ref` has gained different semantics with DIP25 (something like scope, more or less), so this might collide with such a change. Anyway, the situation in D is not the same as in C++, because `ref` is not a type modifier, but a storage class.
