On 14/07/14 18:16, H. S. Teoh via Digitalmars-d wrote:
Mine is here:
http://wiki.dlang.org/User:Quickfur/DIP_scope
From the DIP:
The 'scope' keyword has been around for years, yet it is barely
implemented and it's unclear just what it's supposed to mean
I don't know if it's worth
On 07/15/2014 08:42 AM, Jacob Carlborg wrote:
On 14/07/14 18:16, H. S. Teoh via Digitalmars-d wrote:
Mine is here:
http://wiki.dlang.org/User:Quickfur/DIP_scope
From the DIP:
The 'scope' keyword has been around for years, yet it is barely
implemented and it's unclear just what
On 15/07/14 01:48, H. S. Teoh via Digitalmars-d wrote:
Yes, but since the extent of this scope is unknown from inside the
function body, it doesn't easily lend itself nicely to check things like
this:
int* ptr;
void func(scope int* arg) {
ptr = arg; // should
On 15/07/14 08:46, simendsjo wrote:
Isn't both 1 and 2 deprecated?
Depends on what you mean by deprecated. People are keep saying that
but it's not. Nothing, except for people saying that, indicates that. No
deprecation message, no warning, nothing about it in the documentation.
Even
On Tuesday, 15 July 2014 at 06:42:20 UTC, Jacob Carlborg wrote:
1. Allocate classes on the stack: scope bar = new Bar()
4. Scope parameters. This is the part that is unclear what is
means/is supposed to mean in the current language
These are actually the same thing: if something is stack
On 15/07/14 14:47, Adam D. Ruppe wrote:
These are actually the same thing: if something is stack allocated, it
must not allow the reference to escape to remain memory safe... and if
the reference is not allowed to escape, stack allocating the object
becomes an obvious automatic optimization.
On Tue, Jul 15, 2014 at 09:19:34AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 15/07/14 01:48, H. S. Teoh via Digitalmars-d wrote:
Yes, but since the extent of this scope is unknown from inside the
function body, it doesn't easily lend itself nicely to check things
like this:
On 2014-07-15 16:58, H. S. Teoh via Digitalmars-d wrote:
But what if 'ptr' is declared in a private binary-only module, and only
the signature of 'func' is known? Then what should 'scope' mean to the
compiler when 'func' is being called from another module?
Hmm, I didn't think of that :(
--
On 13/07/14 16:37, H. S. Teoh via Digitalmars-d wrote:
We could, but how would that help static analysis within the function's
body, since the caller's scope is unknown?
Won't the caller's scope always outlive the callee's?
--
/Jacob Carlborg
On Sun, Jul 13, 2014 at 02:58:27PM +, via Digitalmars-d wrote:
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via Digitalmars-d wrote:
Maybe what we should do, is to have everyone post their current
(probably incomplete) drafts of what scope should do, so that we have
everything on
On Mon, Jul 14, 2014 at 10:41:10AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 13/07/14 16:37, H. S. Teoh via Digitalmars-d wrote:
We could, but how would that help static analysis within the
function's body, since the caller's scope is unknown?
Won't the caller's scope always
On 2014-07-11 16:29, H. S. Teoh via Digitalmars-d wrote:
Because the scope of the parameter 'obj' is defined to be the scope of
myFunc only, according to the current proposal.
Wouldn't it be possible to define the scope of a parameter to the
caller's scope?
--
/Jacob Carlborg
On Sun, Jul 13, 2014 at 12:07:58PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-07-11 16:29, H. S. Teoh via Digitalmars-d wrote:
Because the scope of the parameter 'obj' is defined to be the scope
of myFunc only, according to the current proposal.
Wouldn't it be possible to
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
Maybe what we should do, is to have everyone post their current
(probably incomplete) drafts of what scope should do, so that
we have
everything on the table and we can talk about what should be
kept, what
should be
On Friday, 11 July 2014 at 21:04:05 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 10, 2014 at 08:10:36PM +, via Digitalmars-d
wrote:
Hmm. Seems that you're addressing a somewhat wider scope than
what I had
in mind. I was thinking mainly of 'scope' as does not escape
the body
of this
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
Along these lines, I'm wondering if turtles all the way down
is the
wrong way of looking at it. Consider, for example, an n-level
deep
nesting of aggregates. If obj.nest1 is const, then
obj.nest1.nest2.x
must also be
I'm bugging around with a similar proposal for a while, but quite
fail to put the last pieces in place. It goes similar in
On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via
Digitalmars-d wrote:
- For function parameters, this lifetime is the scope of the
function
body.
Some
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
Instead of lifetime intersections with `` (I believe Timon
proposed that in the original thread), simply specify multiple
owners: `scope!(a, b)`. This works, because as far as I can
see there is no need for lifetime unions, only
On 10/07/14 20:15, H. S. Teoh via Digitalmars-d wrote:
class C {}
C myFunc(C obj) {
obj.doSomething();
return obj; // will be rejected if parameters are scoped by
default
}
Hmm, why wouldn't that work? The scope where you called myFunc
On Fri, Jul 11, 2014 at 08:56:10AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 10/07/14 20:15, H. S. Teoh via Digitalmars-d wrote:
class C {}
C myFunc(C obj) {
obj.doSomething();
return obj; // will be rejected if parameters are scoped by
On Friday, 11 July 2014 at 06:49:26 UTC, deadalnix wrote:
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
Instead of lifetime intersections with `` (I believe Timon
proposed that in the original thread), simply specify multiple
owners: `scope!(a, b)`. This works, because as far
On Thu, Jul 10, 2014 at 08:10:36PM +, via Digitalmars-d wrote:
I've been working on a proposal for ownership and borrowing since some
time, and I seem to have come to a very similar result as you have. It
is not really ready, because I keep discovering weaknesses, and can
only work on it
On Fri, Jul 11, 2014 at 06:41:47AM +, deadalnix via Digitalmars-d wrote:
[...]
On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d
wrote:
- For function parameters, this lifetime is the scope of the
function body.
Some kind of inout scope seem less limiting.
Moving this to a new thread as suggested by Jacob.
On Wed, Jul 09, 2014 at 04:57:01PM -0700, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jul 09, 2014 at 03:16:37PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
https://issues.dlang.org/show_bug.cgi?id=13085
[...]
Hmm, apparently,
On Thu, Jul 10, 2014 at 01:56:39PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 10/07/14 01:57, H. S. Teoh via Digitalmars-d wrote:
[...]
I'm sure there are plenty of holes in this proposal, so destroy away.
;-)
You should post this in a new thread.
Done.
I'm wondering if a lot
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
snip
That's curious. I actually replied to H. S. Teoh in his new
thread, but somehow it ended up here...
I've been working on a proposal for ownership and borrowing since
some time, and I seem to have come to a very similar result as
you have. It is not really ready, because I keep discovering
weaknesses, and can only work on it in my free time, but I'm glad
this topic is finally addressed. I'll
On Thu, 10 Jul 2014 20:10:36 +, Marc Schütz wrote:
So, that's it, for now. Sorry for the long text.
Thoughts?
This is crazy interesting, thanks for writing it up. Need to digest it a
bit before offering more feedback.
On Thursday, 10 July 2014 at 20:13:18 UTC, Marc Schütz wrote:
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
snip
That's curious. I actually replied to H. S. Teoh in his new
thread, but somehow it ended up here...
You are in the new thread...
On Thursday, 10 July 2014 at 20:39:45 UTC, John Colvin wrote:
On Thursday, 10 July 2014 at 20:13:18 UTC, Marc Schütz wrote:
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
snip
That's curious. I actually replied to H. S. Teoh in his new
thread, but somehow it ended up here...
On 07/10/2014 10:10 PM, Marc Schütz schue...@gmx.net wrote:
...
Instead of lifetime intersections with `` (I believe Timon proposed
that in the original thread)
I didn't. I suggested that _some_ suitable syntax might need to be found. :)
The root cause of the problem here is the call to
On Thursday, 10 July 2014 at 21:01:23 UTC, Timon Gehr wrote:
On 07/10/2014 10:10 PM, Marc Schütz schue...@gmx.net wrote:
...
Instead of lifetime intersections with `` (I believe Timon
proposed
that in the original thread)
I didn't. I suggested that _some_ suitable syntax might need to
be
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
struct S {
int* p;
void releaseBuffer() scope {
// `scope` in the signature applies to `this`
free(this.p);
this.p = null;
}
}
int bar(scope ref S a, scope int*
On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via
Digitalmars-d wrote:
Can you copy and paste the text from your original post? It's
difficult to read on the web interface.
On Thursday, 10 July 2014 at 18:16:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
There is an interesting subtlety here, in that local variables
themselves are not necessarily scoped, for example:
class C {}
C createObj() {
auto obj = new C; // obj is a local
On Fri, Jul 11, 2014 at 01:01:20AM +, Meta via Digitalmars-d wrote:
On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d
wrote:
Can you copy and paste the text from your original post? It's
difficult to read on the web interface.
I'm working on a DIP for this,
36 matches
Mail list logo
