On 4/2/2015 4:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
But I hope overloading is included under point 1. It's very important for
efficiency.
I'm not convinced of the need for overloading on 'scope'.
Walter Bright:
I'm not convinced of the need for overloading on 'scope'.
Do you want to explain some of the advantages and disadvantages
of that? It will help understand your reasons.
Bye,
bearophile
On Thu, 02 Apr 2015 08:45:10 +0200, Jacob Carlborg wrote:
Why should the non-template
functions that _have_ the source code available suffer?
'cause inferring attributes requires running full semantic analysis on
the code, so each imported function *must* be fully processed. and with
On 4/1/15 11:45 PM, Jacob Carlborg wrote:
On 2015-04-01 22:26, Walter Bright wrote:
The problem with inferring attributes on non-template functions is the
source must be available to the compiler. That's obviously true for
templates, but not so true for non-templates, where only the signature
On 2015-04-01 22:26, Walter Bright wrote:
The problem with inferring attributes on non-template functions is the
source must be available to the compiler. That's obviously true for
templates, but not so true for non-templates, where only the signature
is available.
In my experience with D,
On Thu, 02 Apr 2015 06:59:40 +, ketmar wrote:
On Thu, 02 Apr 2015 08:45:10 +0200, Jacob Carlborg wrote:
Why should the non-template functions that _have_ the source code
available suffer?
'cause inferring attributes requires running full semantic analysis on
the code, so each
On Wednesday, 1 April 2015 at 23:03:02 UTC, bearophile wrote:
Walter Bright:
I'm thinking of a modest step which would be a subset of your
proposal:
1. implement 'scope' and 'return' for arrays, classes, and
pointers
2. implement inference for templates and lambdas
3. enable it with the
On 2015-04-02 08:59, ketmar wrote:
'cause inferring attributes requires running full semantic analysis on
the code, so each imported function *must* be fully processed.
Isn't this required anyway?
--
/Jacob Carlborg
On Thu, 02 Apr 2015 13:39:01 +0200, Jacob Carlborg wrote:
On 2015-04-02 08:59, ketmar wrote:
'cause inferring attributes requires running full semantic analysis on
the code, so each imported function *must* be fully processed.
Isn't this required anyway?
.di files has no function bodies,
On Thu, 02 Apr 2015 16:04:59 +0200, Jacob Carlborg wrote:
On 2015-04-02 14:02, ketmar wrote:
.di files has no function bodies, yet they still works. so compiler
*can*
do full processing, but it is not required, and if compiler does that,
this restriction can be removed in the future. but
On 2015-04-02 14:02, ketmar wrote:
.di files has no function bodies, yet they still works. so compiler *can*
do full processing, but it is not required, and if compiler does that,
this restriction can be removed in the future. but with automatic
inference for functions we are stuck with full
On Tuesday, 31 March 2015 at 20:07:19 UTC, Walter Bright wrote:
Consider the code:
struct Foo { C obj; }
@safe void bar(C c, Foo* f) { f.obj = c; }
Under the proposal, for @safe code, this would have to be
written as:
@safe void bar(static C c, Foo* f) ...
Either that, or:
On 4/1/2015 10:00 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
On Tuesday, 31 March 2015 at 20:07:19 UTC, Walter Bright wrote:
Consider the code:
struct Foo { C obj; }
@safe void bar(C c, Foo* f) { f.obj = c; }
Under the proposal, for @safe code, this would have to be written
Walter Bright:
I'm thinking of a modest step which would be a subset of your
proposal:
1. implement 'scope' and 'return' for arrays, classes, and
pointers
2. implement inference for templates and lambdas
3. enable it with the -dip25 switch
and see how far that takes us.
This is
On 3/15/2015 7:10 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the implementation, and a
more formal specification, as well as a discussion of
On Sunday, 15 March 2015 at 14:10:02 UTC, Marc Schütz wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the
implementation, and a more formal specification, as well as a
discussion of backwards
On 3/22/15 12:29 PM, Andrei Alexandrescu wrote:
Then I also need to get diverted into PR work like improving byLine.
Here PR stands for Public Relations. -- Andrei
On 3/22/15 10:20 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Sunday, 15 March 2015 at 14:10:02 UTC, Marc Schütz wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the
On Wednesday, 18 March 2015 at 13:01:50 UTC, Oren Tirosh wrote:
The scope storage class is a two way contract. The function
promises not to escape the reference. The caller promises to
ensure the storage that the reference is pointing to will
remain valid for the duration of the function call.
On Sunday, 15 March 2015 at 19:11:36 UTC, Marc Schütz wrote:
On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
On 15/03/2015 14:10, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's
On Wednesday, 18 March 2015 at 13:01:50 UTC, Oren Tirosh wrote:
On Sunday, 15 March 2015 at 19:11:36 UTC, Marc Schütz wrote:
On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
On 15/03/2015 14:10, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Here's the new version of my
On Tuesday, 17 March 2015 at 01:13:41 UTC, Zach the Mystic wrote:
On Monday, 16 March 2015 at 20:50:46 UTC, Marc Schütz wrote:
It works just the same:
struct S {
private int* payload_;
ref int* payload() return {
return payload_;
}
}
ref int* payload(scope ref S __this) return
On Monday, 16 March 2015 at 20:50:46 UTC, Marc Schütz wrote:
On Monday, 16 March 2015 at 19:43:01 UTC, Zach the Mystic wrote:
I always tend to think of member functions as if they weren't:
struct S {
T t;
ref T fun() return {
return t;
}
}
In my head, I just translate fun() above to:
On Monday, 16 March 2015 at 04:00:51 UTC, Zach the Mystic wrote:
Functions and methods can be overloaded on scope. This allows
efficient passing of RC wrappers for instance...
How does the compiler figure out which of the variables it's
passing to the parameters are `scope` or not? Does the
On Monday, 16 March 2015 at 12:21:17 UTC, Nick Treleaven wrote:
On 15/03/2015 19:11, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
I too want a scope attribute e.g. for safe slicing of static
arrays,
etc. I'm not sure if
Marc Schütz:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
Let's see what Andrei and Walter think about this all :-)
Bye,
bearophile
On 15/03/2015 19:11, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
I too want a scope attribute e.g. for safe slicing of static arrays,
etc. I'm not sure if it's too late for scope by default though, perhaps.
If we get
On 16/03/2015 04:00, Zach the Mystic wrote:
struct RC(T) if(is(T == class)) {
scope T payload;
T borrow() return {// `return` applies to `this`
return payload;
}
}
...
Also, what exactly does the `scope` on T payload get you?
It means if you forget the `return`
On Monday, 16 March 2015 at 13:55:43 UTC, Marc Schütz wrote:
Also, what exactly does the `scope` on T payload get you? Is
it just a more specific version of `return` on the this
parameter, i.e. `return this.payload`? Why would you need that
specificity? What is the dangerous operation it is
On Monday, 16 March 2015 at 15:25:45 UTC, Zach the Mystic wrote:
If an RC'd struct is heap-allocated, but one of its members
points to the stack, how is it ever safe to escape it?
It isn't.
Why shouldn't the heap variable be treated as scoped too,
inheriting the most restricted scope of any
On Monday, 16 March 2015 at 13:55:43 UTC, Marc Schütz wrote:
On Monday, 16 March 2015 at 04:00:51 UTC, Zach the Mystic wrote:
Functions and methods can be overloaded on scope. This allows
efficient passing of RC wrappers for instance...
How does the compiler figure out which of the variables
On Monday, 16 March 2015 at 19:43:01 UTC, Zach the Mystic wrote:
On Monday, 16 March 2015 at 17:00:12 UTC, Marc Schütz wrote:
BUt there is indeed still some confusion on my side. It's
about the question whether `this` should implicitly be passed
as `scope` or not. Because if it is, scope
On Monday, 16 March 2015 at 17:00:12 UTC, Marc Schütz wrote:
BUt there is indeed still some confusion on my side. It's about
the question whether `this` should implicitly be passed as
`scope` or not. Because if it is, scope members are probably
useless, because they are already implied. I
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the
implementation, and a more formal specification, as well as a
discussion of backwards compatibility. But I thought I'd show
what I have, so that it
On 15/03/2015 14:10, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the implementation,
and a more formal specification, as well as a discussion of
On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote:
On 15/03/2015 14:10, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the
On Sunday, 15 March 2015 at 14:10:02 UTC, Marc Schütz wrote:
Here's the new version of my scope proposal:
http://wiki.dlang.org/User:Schuetzm/scope2
It's still missing real-life examples, a section on the
implementation, and a more formal specification, as well as a
discussion of backwards
37 matches
Mail list logo
