On Thu, 08 Mar 2012 17:43:34 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 08/03/2012 19:38, Steven Schveighoffer wrote:
snip
Yes, I couldn't really find that. It does specifically say casting away
const and then
modifying is invalid, but it does not say anything about if you know
On 19/02/2012 14:27, Stewart Gordon wrote:
snip
int opApply(int delegate(ref inout(T)) dg) inout;
But then I realised a potential ambiguity:
(a) the constancy is passed through to the delegate
(b) the delegate has an inout parameter in its own right
snip
Thinking about it, if we go with (a),
On Fri, 09 Mar 2012 19:44:20 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 19/02/2012 14:27, Stewart Gordon wrote:
snip
int opApply(int delegate(ref inout(T)) dg) inout;
But then I realised a potential ambiguity:
(a) the constancy is passed through to the delegate
(b) the delegate has
On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/07/2012 11:37 PM, Stewart Gordon wrote:
On 07/03/2012 15:41, Steven Schveighoffer wrote:
snip
In fact, I think this is valid D code:
int i;
const int *pi = i;
int *p = cast()pi;
*p = 5; // legal because I know this
On 03/08/2012 12:37 PM, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/07/2012 11:37 PM, Stewart Gordon wrote:
On 07/03/2012 15:41, Steven Schveighoffer wrote:
snip
In fact, I think this is valid D code:
int i;
const int *pi = i;
On Thu, 08 Mar 2012 13:17:15 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/08/2012 12:37 PM, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 03/07/2012 11:37 PM, Stewart Gordon wrote:
On 07/03/2012 15:41, Steven Schveighoffer
On 08/03/2012 19:38, Steven Schveighoffer wrote:
snip
Yes, I couldn't really find that. It does specifically say casting away const
and then
modifying is invalid, but it does not say anything about if you know the
underlying data
is mutable. But again, this is the point I was trying to make,
On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
...
There are two parts to inout, one is that it can be one function called
3 different ways, the other is that you know it's constant during
function execution. Some
On 07/03/2012 15:41, Steven Schveighoffer wrote:
snip
In fact, I think this is valid D code:
int i;
const int *pi = i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 07/03/2012 15:41, Steven Schveighoffer wrote:
snip
In fact, I think this is valid D code:
int i;
const int *pi = i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really
mutable
On 07/03/2012 22:48, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon smjg_1...@yahoo.com wrote:
snip
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
Sorry, it's just easier than typing cast(int*).
Which is another abomination.
On Wed, 07 Mar 2012 18:01:10 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 07/03/2012 22:48, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
snip
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that
it
On 03/07/2012 11:37 PM, Stewart Gordon wrote:
On 07/03/2012 15:41, Steven Schveighoffer wrote:
snip
In fact, I think this is valid D code:
int i;
const int *pi = i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really mutable
cast() is an abomination. I'm not
On 03/07/2012 04:41 PM, Steven Schveighoffer wrote:
On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
...
There are two parts to inout, one is that it can be one function called
3 different ways, the other is that you
On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
...
There are two parts to inout, one is that it can be one function called
3 different ways, the other is that you know it's constant during
function execution. Some people like that second part, even if it
doesn't fully guarantee everything.
On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 02/24/2012 05:26 PM, Steven Schveighoffer wrote:
On Sun, 19 Feb 2012 09:27:42 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
At the moment, if a function has an inout parameter, it must have an
inout return type.
On 05/03/2012 13:49, Steven Schveighoffer wrote:
On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr timon.g...@gmx.ch wrote:
snip
inout means 'some qualifier but we don't know which one'. The call site on the
other
hand knows which qualifier it is. If the call is made to work there is no
'making
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
snip
inout means 'some qualifier but we don't know which one'. The call
site on the other
On 03/05/2012 11:31 PM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
snip
inout means 'some qualifier but we
On Mon, 05 Mar 2012 18:01:34 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/05/2012 11:31 PM, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
On Sat, 25 Feb 2012 09:02:47 -0500,
On 05/03/2012 22:31, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon smjg_1...@yahoo.com wrote:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
snip
It's currently transitive, and this would break transitivity. If we want to
look at
fundamentally redefining
On Mon, 05 Mar 2012 20:34:09 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
On 05/03/2012 22:31, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
snip
It's currently transitive,
On 02/24/2012 05:26 PM, Steven Schveighoffer wrote:
On Sun, 19 Feb 2012 09:27:42 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
At the moment, if a function has an inout parameter, it must have an
inout return type.
But this prevents doing stuff like
void test(ref inout(int)[] x,
On Sun, 19 Feb 2012 09:27:42 -0500, Stewart Gordon smjg_1...@yahoo.com
wrote:
At the moment, if a function has an inout parameter, it must have an
inout return type.
But this prevents doing stuff like
void test(ref inout(int)[] x, inout(int)[] y) {
x = y;
}
This is a
At the moment, if a function has an inout parameter, it must have an inout
return type.
But this prevents doing stuff like
void test(ref inout(int)[] x, inout(int)[] y) {
x = y;
}
or passing the constancy through to a delegate instead of a return value.
A typical use case of
On 02/19/2012 03:27 PM, Stewart Gordon wrote:
At the moment, if a function has an inout parameter, it must have an
inout return type.
But this prevents doing stuff like
void test(ref inout(int)[] x, inout(int)[] y) {
x = y;
}
or passing the constancy through to a delegate instead of a return
On 19/02/2012 15:31, Timon Gehr wrote:
snip excessive quote
snip
a) int opApply(inout int delegate(ref inout(T)) dg) inout;
b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;
???
Actually affecting the constancy of the delegate itself is not an useful
operation anyway,
On 02/19/2012 06:09 PM, Stewart Gordon wrote:
On 19/02/2012 15:31, Timon Gehr wrote:
snip excessive quote
snip
a) int opApply(inout int delegate(ref inout(T)) dg) inout;
b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;
???
oops...
a) int opApply(inout int delegate(ref
I think the 'scope' keyword may resolve issue.
Attributes of lazy parameter in template function belong to caller side.
int foo()(lazy int value) @safe pure /*nothrow*/ { return value(); }
void main() {
int n = foo(10);
// evaluating lazy parameter never break safety and purity of foo.
On 02/19/2012 11:27 PM, kenji hara wrote:
I think the 'scope' keyword may resolve issue.
Attributes of lazy parameter in template function belong to caller side.
int foo()(lazy int value) @safe pure /*nothrow*/ { return value(); }
void main() {
int n = foo(10);
// evaluating lazy
30 matches
Mail list logo
