On 5/16/2014 1:18 PM, Dicebot wrote:
Also I believe `scope` is one of concepts that are hard to define but incredibly
easy to grasp intuitively.
How and where to put the annotations, and the notion of transitivity, are not so
incredibly easy to grasp. The mix of ref and scope is also a bit of
On Friday, 16 May 2014 at 18:57:34 UTC, Walter Bright wrote:
On 5/16/2014 10:33 AM, Dicebot wrote:
On Friday, 16 May 2014 at 17:22:21 UTC, Walter Bright wrote:
On 5/16/2014 9:43 AM, Dicebot wrote:
Transitive
borrowing solves certain class of issues that currently rely
on convention,
enabling
On Fri, May 16, 2014 at 11:57:36AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/16/2014 10:33 AM, Dicebot wrote:
> >On Friday, 16 May 2014 at 17:22:21 UTC, Walter Bright wrote:
> >>On 5/16/2014 9:43 AM, Dicebot wrote:
> >>>Transitive borrowing solves certain class of issues that currently
>
On 5/16/2014 10:33 AM, Dicebot wrote:
On Friday, 16 May 2014 at 17:22:21 UTC, Walter Bright wrote:
On 5/16/2014 9:43 AM, Dicebot wrote:
Transitive
borrowing solves certain class of issues that currently rely on convention,
enabling whole new type of verified safe code (both memory safe and conc
On Friday, 16 May 2014 at 17:22:21 UTC, Walter Bright wrote:
On 5/16/2014 9:43 AM, Dicebot wrote:
Transitive
borrowing solves certain class of issues that currently rely
on convention,
enabling whole new type of verified safe code (both memory
safe and concurrency
safe). Head-only? Doesn't lo
On 5/16/2014 9:43 AM, Dicebot wrote:
Transitive
borrowing solves certain class of issues that currently rely on convention,
enabling whole new type of verified safe code (both memory safe and concurrency
safe). Head-only? Doesn't look so.
I'm concerned that transitive borrowing will *preclude*
On Thursday, 15 May 2014 at 18:08:06 UTC, Walter Bright wrote:
get() is returning a pointer to its internally managed data (in
the form of []). You're right that transitivity of borrowing
would support this safely, but I am not proposing that for ref.
To make slicing Buffer safe, one would have
On 5/15/2014 5:18 AM, Dicebot wrote:
On Wednesday, 14 May 2014 at 19:03:20 UTC, Walter Bright wrote:
The idea is that 'ref' are borrowed pointers, so if you're returning pointers,
the borrowed semantics do not apply.
Somewhat more extended example:
struct Buffer
{
private byte[] data;
On Wednesday, 14 May 2014 at 19:03:20 UTC, Walter Bright wrote:
Also A can only control escaping of any internal references
only by completely
prohibiting access to it which is not good. You have no
means to say "feel free
to use this reference as long as you don't keep it outside
of current sc
On 5/14/2014 6:09 AM, Dicebot wrote:
On Tuesday, 13 May 2014 at 20:46:19 UTC, Walter Bright wrote:
On 5/13/2014 12:06 PM, Dicebot wrote:
No, it still can be necessary. `scope` can greatly help not only with resource
releasing, it is also missing tool to safely cast from shared. Locking shared
v
On 2014-05-14 15:00, Dicebot wrote:
To be a reference ;) But yeah, it is not important in this example,
plain scope should behave the same if transitive.
I though that "A" was a class in the previous example, but now I see
that it was a struct.
--
/Jacob Carlborg
On Tuesday, 13 May 2014 at 20:46:19 UTC, Walter Bright wrote:
On 5/13/2014 12:06 PM, Dicebot wrote:
No, it still can be necessary. `scope` can greatly help not
only with resource
releasing, it is also missing tool to safely cast from shared.
Locking shared
variable can return same variable cast
On Tuesday, 13 May 2014 at 19:17:16 UTC, Jacob Carlborg wrote:
What is "scope ref" supposed to do in this example, compared to
just "scope"?
To be a reference ;) But yeah, it is not important in this
example, plain scope should behave the same if transitive.
On 5/14/2014 12:29 AM, Idan Arye wrote:
On Tuesday, 13 May 2014 at 17:44:02 UTC, Walter Bright wrote:
On 5/13/2014 6:50 AM, Dicebot wrote:
Walter's initial post implies that he wanted to re-used `ref` for borrowed
pointer (which would mean same semantics as `scope` parameter qualifier)
'ref'
On Tuesday, 13 May 2014 at 17:44:02 UTC, Walter Bright wrote:
On 5/13/2014 6:50 AM, Dicebot wrote:
Walter's initial post implies that he wanted to re-used `ref`
for borrowed
pointer (which would mean same semantics as `scope` parameter
qualifier)
'ref' already is to much extent, for example:
On 5/13/2014 1:46 PM, Walter Bright wrote:
I believe that is the role of `unique`. DIP69 addresses making unique pointers
in D, and there have been several PR's implementing aspects of it.
Argh, DIP29:
http://wiki.dlang.org/DIP29
On 5/13/2014 12:06 PM, Dicebot wrote:
No, it still can be necessary. `scope` can greatly help not only with resource
releasing, it is also missing tool to safely cast from shared. Locking shared
variable can return same variable casted to scope qualifier which will
guarantee that no reference ha
On 2014-05-13 19:52, Dicebot wrote:
It has to be transitive to be useful as borrowed pointer. Consider this
example:
{
scope A a; // has some internally managed resources
foo(a);
}
It is not safe to destruct a in the end of the scope here because foo
may have stored references to a o
On Tuesday, 13 May 2014 at 18:48:14 UTC, Walter Bright wrote:
On 5/13/2014 10:52 AM, Dicebot wrote:
It has to be transitive to be useful as borrowed pointer.
Consider this example:
{
scope A a; // has some internally managed resources
foo(a);
}
It is not safe to destruct a in the end
On 5/13/2014 10:52 AM, Dicebot wrote:
It has to be transitive to be useful as borrowed pointer. Consider this example:
{
scope A a; // has some internally managed resources
foo(a);
}
It is not safe to destruct a in the end of the scope here because foo may have
stored references to a
On 5/13/2014 11:21 AM, Steven Schveighoffer wrote:
I'm not certain I understand the concept correctly, but from Dicebot's code
example, it is transitive.
I know Dicebot's example assumes a transitivity property, but I question that
assumption.
In my cursory reading of Rust documentation, it
On Tue, 13 May 2014 13:51:21 -0400, Walter Bright
wrote:
On 5/13/2014 10:09 AM, Steven Schveighoffer wrote:
Yes, the difference here is that scope is a storage class, and only
affects the
"head", whereas borrowed would have to be transitive.
Are you sure it would have to be transitive?
On 5/13/2014 10:09 AM, Steven Schveighoffer wrote:
Yes, the difference here is that scope is a storage class, and only affects the
"head", whereas borrowed would have to be transitive.
Are you sure it would have to be transitive?
On Tuesday, 13 May 2014 at 17:41:23 UTC, Walter Bright wrote:
On 5/13/2014 6:36 AM, Dicebot wrote:
Main problem about making `ref` borrowed pointer is that you
will need to
prohibit storing it in function transitively. This will need
to become invalid
code:
struct A
{
int* ptr;
}
int* gp
On 5/13/2014 6:36 AM, Dicebot wrote:
Main problem about making `ref` borrowed pointer is that you will need to
prohibit storing it in function transitively. This will need to become invalid
code:
struct A
{
int* ptr;
}
int* gptr;
void foo(ref A a)
{
gptr = a.ptr; // error, can't leak
On 5/13/2014 6:50 AM, Dicebot wrote:
Walter's initial post implies that he wanted to re-used `ref` for borrowed
pointer (which would mean same semantics as `scope` parameter qualifier)
'ref' already is to much extent, for example:
@safe int foo(ref int x) {
auto a = &x;
return 3;
}
On Tuesday, 13 May 2014 at 17:09:17 UTC, Steven Schveighoffer
wrote:
On Tue, 13 May 2014 09:50:12 -0400, Dicebot
wrote:
On Tuesday, 13 May 2014 at 13:40:42 UTC, Jacob Carlborg wrote:
On 13/05/14 15:36, Dicebot wrote:
There are 2 `scope` uses to think about. One is storage
class and in
that
On Tue, 13 May 2014 09:50:12 -0400, Dicebot wrote:
On Tuesday, 13 May 2014 at 13:40:42 UTC, Jacob Carlborg wrote:
On 13/05/14 15:36, Dicebot wrote:
There are 2 `scope` uses to think about. One is storage class and in
that context `scope` is more of owned / unique pointer. Other is
parameter
On Tuesday, 13 May 2014 at 13:40:42 UTC, Jacob Carlborg wrote:
On 13/05/14 15:36, Dicebot wrote:
There are 2 `scope` uses to think about. One is storage class
and in
that context `scope` is more of owned / unique pointer. Other
is
parameter qualifier and that one is closer to ref / borrowed
p
On 13/05/14 15:36, Dicebot wrote:
There are 2 `scope` uses to think about. One is storage class and in
that context `scope` is more of owned / unique pointer. Other is
parameter qualifier and that one is closer to ref / borrowed pointer.
Main problem about making `ref` borrowed pointer is that
On Monday, 12 May 2014 at 20:36:10 UTC, Walter Bright wrote:
It's been brought up more than once that the 'scope' storage
class is an unimplemented borrowed pointer. But thinking a bit
more along those lines, actually 'ref' fills the role of a
borrowed pointer.
One particularly apropos behavi
On Tuesday, 13 May 2014 at 04:46:41 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-05-13 at 04:07 +, logicchains via
Digitalmars-d wrote:
[…]
This sounds a bit like an 'issue' of sorts that Rust has with
borrowed pointers, where certain types of datastructures
cannot be written w
On Tue, 2014-05-13 at 04:07 +, logicchains via Digitalmars-d wrote:
[…]
> This sounds a bit like an 'issue' of sorts that Rust has with
> borrowed pointers, where certain types of datastructures cannot
> be written without resorting to the 'unsafe' parts of the
> language. The solution they'
On 13 May 2014 06:36, Walter Bright via Digitalmars-d
wrote:
> It's been brought up more than once that the 'scope' storage class is an
> unimplemented borrowed pointer. But thinking a bit more along those lines,
> actually 'ref' fills the role of a borrowed pointer.
>
> One particularly apropos b
On Monday, 12 May 2014 at 21:15:38 UTC, Steven Schveighoffer
wrote:
Hm... the one piece that I think would be damaging is to not be
able to take an address of the 'this' reference. It's probably
OK to just use pointers and static functions in some cases, but
member functions do not have that lu
On 5/12/2014 2:15 PM, Steven Schveighoffer wrote:
Hm... the one piece that I think would be damaging is to not be able to take an
address of the 'this' reference. It's probably OK to just use pointers and
static functions in some cases, but member functions do not have that luxury. In
other words
On Monday, 12 May 2014 at 20:36:10 UTC, Walter Bright wrote:
It's been brought up more than once that the 'scope' storage
class is an unimplemented borrowed pointer. But thinking a bit
more along those lines, actually 'ref' fills the role of a
borrowed pointer.
One particularly apropos behavi
On 05/12/2014 10:36 PM, Walter Bright wrote:
It's been brought up more than once that the 'scope' storage class is an
unimplemented borrowed pointer. But thinking a bit more along those lines,
actually 'ref' fills the role of a borrowed pointer.
One particularly apropos behavior is that struct
On Mon, 12 May 2014 16:36:12 -0400, Walter Bright
wrote:
It's been brought up more than once that the 'scope' storage class is an
unimplemented borrowed pointer. But thinking a bit more along those
lines, actually 'ref' fills the role of a borrowed pointer.
One particularly apropos behav
The first thing that comes to my mind is applying this somehow to
the (T) vs (ref T) function problem. (const ref, scope ref,
references to r-values, you know the problem.) At the moment I
just follow this pattern.
void foo(ref const T bar) {
/* ... */
}
// Second overload to make r-value
On 5/12/2014 2:13 PM, Walter Bright wrote:
On 5/12/2014 1:49 PM, Kagamin wrote:
How would you assign a borrowed pointer?
A ref could only be assigned to another ref.
I mean to a ref of the same or smaller scope.
On 5/12/2014 1:49 PM, Kagamin wrote:
How would you assign a borrowed pointer?
A ref could only be assigned to another ref.
How would you assign a borrowed pointer?
It's been brought up more than once that the 'scope' storage class is an
unimplemented borrowed pointer. But thinking a bit more along those lines,
actually 'ref' fills the role of a borrowed pointer.
One particularly apropos behavior is that struct member functions pass 'this' by
ref, meaning
44 matches
Mail list logo
