On Thursday, 10 January 2013 at 16:42:09 UTC, Tommi wrote:
...which won't compile because T(4) is an rvalue, and according
to D, rvalues can't be passed as ref (nor const ref). I don't
know which one is flawed, my analogy, or the logic of how D is
designed.
My analogy is a bit broken in the s
...Although, I should add that my analogy between methods and
free functions seems to break when the object is an rvalue. Like
in:
struct T
{
int v;
this(int a)
{
v = a;
}
int get()
{
return v;
}
}
int v = T(4).get();
Given my analogy, the method
On Thursday, 3 January 2013 at 21:56:22 UTC, David Nadlinger
wrote:
I must admit that I haven't read the rest of the thread yet,
but I think the obvious and correct solution is to disallow
passing locals (including non-ref parameters, which are
effectively locals in D) as non-scope ref argument
On Sunday, 30 December 2012 at 22:02:16 UTC, Jonathan M Davis
wrote:
But that's
very different from any attribute that we currently have. It
would be like
having a throw attribute instead of a nothrow attribute. I
suppose that it is
a possible solution though. I could also see an argument that
On Wednesday, 9 January 2013 at 04:33:21 UTC, Zach the Mystic
wrote:
I felt confident enough about my proposal to submit it as
enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=9283
By the way, what do you propose is the correct placement of this
"new" out keyword:
#1: out
On Wednesday, 9 January 2013 at 04:33:21 UTC, Zach the Mystic
wrote:
I felt confident enough about my proposal to submit it as
enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=9283
I like it. One issue though, like you also indicated by putting
question marks on it:
ref T
On Friday, 4 January 2013 at 20:20:08 UTC, Jonathan M Davis wrote:
On Friday, January 04, 2013 17:26:59 Zach the Mystic wrote:
> Honestly though, I'm inclined to argue that functions which
> return by ref and
> have a ref parameter of that same type just be considered
> @system.
Structs mess th
I've here formalized how I think the constraints on a non-scope
ref taking and ref returning function should work. This
represents a whole addition to the type system. The attribute
"@outref" from my previous post has been shortened to keyword
"out" (must come before parentheses). This is all I
On Friday, 4 January 2013 at 20:20:08 UTC, Jonathan M Davis wrote:
... But it doesn't change the
statement that a function which takes a parameter by ref and
returns by ref
can't be considered @safe without additional constraints of
some kind. It just
shows why you don't have an easy way out to
On Friday, January 04, 2013 17:26:59 Zach the Mystic wrote:
> > Honestly though, I'm inclined to argue that functions which
> > return by ref and
> > have a ref parameter of that same type just be considered
> > @system.
>
> Structs mess that up as well:
> struct S { int i; }
> ref int d(ref S s)
On Sunday, 30 December 2012 at 22:02:16 UTC, Jonathan M Davis
wrote:
The closest that we could get to what you suggest would be to
add a new
attribute similar to nothrow but which guarantees that the
function does not
return a ref to a parameter. So, you'd have to mark your
functions that way
(
On Friday, 4 January 2013 at 14:15:01 UTC, Tommi wrote:
'Tainting function call':
A call to a 'tainter function' where at least one of the
arguments passed by reference is ref to a local variable
I forgot to point out that the return value of a 'tainting
function call' is considered to
On Friday, 4 January 2013 at 06:30:55 UTC, Sönke Ludwig wrote:
In other words, references returned by a function call that
took any references to locals would be
tainted as possibly local (in the function local data flow) and
thus are not allowed to escape the
scope. References derived from non-
On Friday, 4 January 2013 at 06:30:55 UTC, Sönke Ludwig wrote:
In other words, references returned by a function call that
took any references to locals would be
tainted as possibly local (in the function local data flow) and
thus are not allowed to escape the
scope. References derived from non-
Am 03.01.2013 00:48, schrieb Jason House:
> On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis wrote:
>> After some recent discussions relating to auto ref and const ref, I have come
>> to the conlusion that as it stands, ref is not @safe. It's @system. And I
>> think that we need to tak
On Friday, 4 January 2013 at 00:46:33 UTC, Araq wrote:
On Wednesday, 2 January 2013 at 23:33:16 UTC, Thiez wrote:
On Wednesday, 2 January 2013 at 22:53:04 UTC, Jonathan M Davis
wrote:
Then we're going to have to disagree, and I believe that
Walter and Andrei are
completely with me on this one.
On Wednesday, 2 January 2013 at 23:33:16 UTC, Thiez wrote:
On Wednesday, 2 January 2013 at 22:53:04 UTC, Jonathan M Davis
wrote:
Then we're going to have to disagree, and I believe that
Walter and Andrei are
completely with me on this one. If all of the constructs that
you use are
@safe, then i
On Thursday, 3 January 2013 at 23:06:03 UTC, David Nadlinger
wrote:
The problem with that idea, is that a ref return with no
arguments may call another ref return that returns something
that escapes the scope it was created in. If the source code
is not available, then there's no way for the co
OK, I understand what you mean by "scope" and how that can be
used to prevent leaking a local ref out.
Don't forget to consider this kind of scenario, which has no ref
arguments to consider
struct X
{
int _i;
ref int f()
{
return _i;
}
}
ref int F()
{
X x;
return x.f
On Thursday, January 03, 2013 23:50:37 Rob T wrote:
> My understanding was that in some cases that source code is not
> available to the compiler, which I would think means that
> preventing scope escaping cannot be 100% guaranteed, correct?
The source code is always available when compiling the f
On Thursday, 3 January 2013 at 22:50:38 UTC, Rob T wrote:
The problem with that idea, is that a ref return with no
arguments may call another ref return that returns something
that escapes the scope it was created in. If the source code is
not available, then there's no way for the compiler to
On Thursday, 3 January 2013 at 22:50:38 UTC, Rob T wrote:
On Thursday, 3 January 2013 at 21:56:22 UTC, David Nadlinger
wrote:
I must admit that I haven't read the rest of the thread yet,
but I think the obvious and correct solution is to disallow
passing locals (including non-ref parameters, wh
On Thursday, 3 January 2013 at 21:56:22 UTC, David Nadlinger
wrote:
I must admit that I haven't read the rest of the thread yet,
but I think the obvious and correct solution is to disallow
passing locals (including non-ref parameters, which are
effectively locals in D) as non-scope ref argument
On Thursday, 3 January 2013 at 21:56:22 UTC, David Nadlinger
wrote:
I must admit that I haven't read the rest of the thread yet,
but I think the obvious and correct solution is to disallow
passing locals (including non-ref parameters, which are
effectively locals in D) as non-scope ref argument
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system. And I
think that we need to take a serious look at it to see what we
can do to m
On 01/03/2013 01:52 PM, Jason House wrote:
On Thursday, 3 January 2013 at 05:56:27 UTC, Timon Gehr wrote:
On 01/03/2013 12:48 AM, Jason House wrote:
...
ref int bar()
{
int i = 7;
return foo(i);
}
If @safe, this code will not compile.
Error: foo may return a local stack variable
Sinc
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
And maybe another solution which I can't think of at the moment
would be
better. But my point is that we currently have a _major_ hole
in SafeD thanks
to the combination of ref parameters and ref return types, and
we need to f
On Thursday, 3 January 2013 at 05:56:27 UTC, Timon Gehr wrote:
On 01/03/2013 12:48 AM, Jason House wrote:
...
ref int bar()
{
int i = 7;
return foo(i);
}
If @safe, this code will not compile.
Error: foo may return a local stack variable
Since "i" is a local variable, "foo(i)" might re
On 01/03/13 00:06, H. S. Teoh wrote:
> All extern(C) functions must be @system by default. It makes no sense to
> allow a @safe extern(C) function, since there is no way for the compiler
> to verify anything at all. The best you can do is @trusted.
extern(C) does not imply extern.
And for extern
On Thursday, 3 January 2013 at 00:13:41 UTC, H. S. Teoh wrote:
On Thu, Jan 03, 2013 at 12:53:56AM +0100, David Nadlinger wrote:
On Wednesday, 2 January 2013 at 23:08:14 UTC, H. S. Teoh wrote:
>All extern(C) functions must be @system by default. It makes
>no sense
>to allow a @safe extern(C) fun
On 01/03/2013 12:48 AM, Jason House wrote:
...
ref int bar()
{
int i = 7;
return foo(i);
}
If @safe, this code will not compile.
Error: foo may return a local stack variable
Since "i" is a local variable, "foo(i)" might return it.
ref int baz(int i)
{
return foo(i);
}
This
On Thu, Jan 03, 2013 at 12:53:56AM +0100, David Nadlinger wrote:
> On Wednesday, 2 January 2013 at 23:08:14 UTC, H. S. Teoh wrote:
> >All extern(C) functions must be @system by default. It makes no sense
> >to allow a @safe extern(C) function, since there is no way for the
> >compiler to verify any
On Wednesday, 2 January 2013 at 23:08:14 UTC, H. S. Teoh wrote:
All extern(C) functions must be @system by default. It makes no
sense to
allow a @safe extern(C) function, since there is no way for the
compiler
to verify anything at all. The best you can do is @trusted.
@trusted shouldn't be a
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system. And I
think that we need to take a serious look at it to see what we
can do to m
On 1/2/13 5:21 PM, Maxim Fomin wrote:
On Wednesday, 2 January 2013 at 19:37:51 UTC, Jonathan M Davis wrote:
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
I think it should not be fixed, but probably compiler may issue
warning at some circumstances when it can realize this situation
On Wed, Jan 02, 2013 at 06:30:38PM -0500, Jonathan M Davis wrote:
> On Wednesday, January 02, 2013 15:06:24 H. S. Teoh wrote:
> > All extern(C) functions must be @system by default. It makes no sense to
> > allow a @safe extern(C) function, since there is no way for the compiler
> > to verify anyth
On Wednesday, 2 January 2013 at 22:53:04 UTC, Jonathan M Davis
wrote:
Then we're going to have to disagree, and I believe that Walter
and Andrei are
completely with me on this one. If all of the constructs that
you use are
@safe, then it should be _guaranteed_ that your program is
memory-safe.
On Wednesday, January 02, 2013 15:06:24 H. S. Teoh wrote:
> All extern(C) functions must be @system by default. It makes no sense to
> allow a @safe extern(C) function, since there is no way for the compiler
> to verify anything at all. The best you can do is @trusted.
Agreed. And @trusted is seri
On Wed, Jan 02, 2013 at 05:52:54PM -0500, Jonathan M Davis wrote:
> On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> > Again, I argue that D is a system language and there are many
> > possibilities to break @safity. Although fixing holes does make
> > sense in general, it does not make
On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> Again, I argue that D is a system language and there are many
> possibilities to break @safity. Although fixing holes does make
> sense in general, it does not make sense fixing obvious issues so
> that plenty of code becomes uncompilable
On Wednesday, 2 January 2013 at 19:37:51 UTC, Jonathan M Davis
wrote:
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
I think it should not be fixed, but probably compiler may issue
warning at some circumstances when it can realize this
situation.
It's a hole in @safe. It must be f
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
> I think it should not be fixed, but probably compiler may issue
> warning at some circumstances when it can realize this situation.
It's a hole in @safe. It must be fixed. That's not even vaguely up for
discussion. The question is _how_
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system.
This is not a surprise, I remember Andrei was talking about it
1.5 year ago.
On Monday, December 31, 2012 22:25:52 Mehrdad wrote:
> I don't understand why there is a discussion on trying to
> special-case ref parameters. There's nothing special about ref
> parameters... what's special is ref _returns_.
>
> Therefore all we need to do is disallow ref returns in @safe code.
On Monday, 31 December 2012 at 23:39:35 UTC, Rob T wrote:
ref returns where the return result cannot be proven to be safe
Halting problem?
On Monday, 31 December 2012 at 21:25:53 UTC, Mehrdad wrote:
I don't understand why there is a discussion on trying to
special-case ref parameters. There's nothing special about ref
parameters... what's special is ref _returns_.
Therefore all we need to do is disallow ref returns in @safe
cod
I don't understand why there is a discussion on trying to
special-case ref parameters. There's nothing special about ref
parameters... what's special is ref _returns_.
Therefore all we need to do is disallow ref returns in @safe code.
On 31/12/2012 14:44, Nick Treleaven wrote:
On 30/12/2012 22:01, Jonathan M Davis wrote:
The closest that we could get to what you suggest would be to add a new
attribute similar to nothrow but which guarantees that the function
does not
return a ref to a parameter. So, you'd have to mark your fu
On 30/12/2012 22:01, Jonathan M Davis wrote:
On Sunday, December 30, 2012 17:32:40 Nick Treleaven wrote:
I think the compiler needs to be able to mark foo as a function that
returns its input reference. Then, any arguments to foo that are locals
should cause an error at the call site (e.g. in ba
On Monday, 31 December 2012 at 02:47:46 UTC, Jonathan M Davis
wrote:
3. Create a new attribute which has to be used when a function
returns a ref
to a parameter and use that to make it illegal to pass a ref to
a local
variable to such functions.
If this is the way to go, maybe "@saferef" co
On 2012-12-30 22:29:33 +, Jonathan M Davis said:
Good point. Member variables of parameters also cause problems. So, it very
quickly devolves to any function which accepts a user-defined type by ref and
returns anything by ref would have to be @system, which is far from pleasant.
Note tha
On Monday, December 31, 2012 03:34:18 Carl Sturtivant wrote:
> The implementation of delegates has solved an analogous problem.
Delegates use closures. The stack of the calling function is copied onto the
heap so that it will continue to be valid for the delegate after the function
returns. We d
/*
The implementation of delegates has solved an analogous problem.
e.g.
*/
import std.stdio;
auto getfun( int x) {
int y = x*x;
int ysquared() {
return y*y;
}
return &ysquared;
}
void main() {
auto f1 = getfun(2);
auto f2 = getf
On Monday, December 31, 2012 02:37:56 Rob T wrote:
> This may be far fetched, but consider this,
>
> If a function returns a ref that is the same as what was passed
> in by ref, then the passed and return addresses would match,
> which means that it still may be possible for the compiler to
> dete
On Sunday, 30 December 2012 at 22:30:24 UTC, Jonathan M Davis
wrote:
On Sunday, December 30, 2012 23:18:43 jerro wrote:
> Honestly though, I'm inclined to argue that functions which
> return by ref and
> have a ref parameter of that same type just be considered
> @system.
What about this:
stru
On Sunday, December 30, 2012 23:18:43 jerro wrote:
> > Honestly though, I'm inclined to argue that functions which
> > return by ref and
> > have a ref parameter of that same type just be considered
> > @system.
>
> What about this:
>
> struct Foo
> {
> int a;
> }
>
> ref int bar(ref Foo fo
Honestly though, I'm inclined to argue that functions which
return by ref and
have a ref parameter of that same type just be considered
@system.
What about this:
struct Foo
{
int a;
}
ref int bar(ref Foo foo)
{
return foo.a;
}
the parameter type and the return type here are different
On Sunday, December 30, 2012 17:32:40 Nick Treleaven wrote:
> I think the compiler needs to be able to mark foo as a function that
> returns its input reference. Then, any arguments to foo that are locals
> should cause an error at the call site (e.g. in baz). So legal calls to
> foo can always be
Here the compiler already knows that foo returns its input
reference. So it checks whether foo is being passed a local -
no; but it also has to check if foo is passed any ref
parameters of quux, which it is. The compiler now has to mark
quux as a function that returns its input reference.
Wor
On Sunday, 30 December 2012 at 17:32:41 UTC, Nick Treleaven wrote:
On 30/12/2012 09:17, Jonathan M Davis wrote:
The problem is the wrapper function.
You'd also have to disallow functions from returning ref
parameters by ref.
Otherwise,
ref int foo(ref int i)
{
return i;
}
ref int baz(int
On 30/12/2012 09:17, Jonathan M Davis wrote:
The problem is the wrapper function.
You'd also have to disallow functions from returning ref parameters by ref.
Otherwise,
ref int foo(ref int i)
{
return i;
}
ref int baz(int i)
{
return foo(i);
}
continues to cause problems. And making
12/30/2012 12:37 PM, Jonathan M Davis пишет:
After some recent discussions relating to auto ref and const ref, I have come
to the conlusion that as it stands, ref is not @safe. It's @system. And I
think that we need to take a serious look at it to see what we can do to make
it @safe. The problem
On Sunday, December 30, 2012 11:04:35 monarch_dodra wrote:
> Wouldn't it be enough to disallow functions that both take and
> return by ref? There would still be some limitations, but at
> least:
>
> //
> @property ref T front(T)(T[] a);
> //
> Would still be @safe.
>
> It seams the only
On Sunday, 30 December 2012 at 09:18:30 UTC, Jonathan M Davis
wrote:
On Sunday, December 30, 2012 10:04:01 Daniel Kozak wrote:
IMHO, try to return ref to local variable should be error, and
such a code shouldn't be compilable
You can disallow that in the easy case of
ref int boo(int i)
{
On Sunday, December 30, 2012 10:04:01 Daniel Kozak wrote:
> IMHO, try to return ref to local variable should be error, and
> such a code shouldn't be compilable
You can disallow that in the easy case of
ref int boo(int i)
{
return i;
}
and in fact, that's already illegal. The problem is the
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system. And I
think that we need to take a serious look at it to see what we
can do to m
After some recent discussions relating to auto ref and const ref, I have come
to the conlusion that as it stands, ref is not @safe. It's @system. And I
think that we need to take a serious look at it to see what we can do to make
it @safe. The problem is combining code that takes ref parameters
67 matches
Mail list logo
