On Monday, 2 March 2015 at 20:40:45 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 20:36:53 UTC, Marc Schütz wrote:
Interesting approach. I will have to think about that. But I
think it does not really work. Your example hides the fact
that there are actually two types involved (or can be):
You don't put the ownership acquire at the same place, but that
is the same idea. It is probably even better to do it your way
(or is it ?).
On Monday, 2 March 2015 at 22:00:56 UTC, deadalnix wrote:
You don't put the ownership acquire at the same place, but that
is the same idea. It is probably even better to do it your way
(or is it ?).
Yes. Unless the compiler detects that you duplicate a variable in
two parameters in the same
On Monday, 2 March 2015 at 20:04:49 UTC, deadalnix wrote:
I let the night go over that one. Here is what I think is the
best road forward :
- triggering postblit and/or ref count bump/decrease is
prohibited on borrowed.
- Acquiring and releasing ownership does.
Now that we have this, let's
On Monday, 2 March 2015 at 22:21:11 UTC, Zach the Mystic wrote:
On Monday, 2 March 2015 at 22:00:56 UTC, deadalnix wrote:
You don't put the ownership acquire at the same place, but
that is the same idea. It is probably even better to do it
your way (or is it ?).
Yes. Unless the compiler
On Tuesday, 3 March 2015 at 00:02:48 UTC, deadalnix wrote:
What do you think? How many times do you normally pass a
global?
I fail too see how t being global vs t being a local that is
doubly passed change anything.
Within the function, the global passed as a parameter creates an
alias to
On Monday, 2 March 2015 at 22:51:29 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 22:21:11 UTC, Zach the Mystic wrote:
On Monday, 2 March 2015 at 22:00:56 UTC, deadalnix wrote:
You don't put the ownership acquire at the same place, but
that is the same idea. It is probably even better to do
On Monday, 2 March 2015 at 23:43:22 UTC, Zach the Mystic wrote:
Except for this:
static Rctype t; //
fun(t);
Now you have that implicit parameter which screws things up.
It's like calling:
fun(@globals, t);
...where @globals is a namespace which can alias t. So you have
two parameters
On Tuesday, 3 March 2015 at 00:47:01 UTC, Andrei Alexandrescu
wrote:
This does not solve anything as postblit only increase
refcount so it
does not make any sense that it deletes the payload.
Yah, it's opAssign instead of postblit. -- Andrei
So it is an auto expanding arena, and when all
On Tuesday, 3 March 2015 at 00:11:36 UTC, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 00:02:48 UTC, deadalnix wrote:
What do you think? How many times do you normally pass a
global?
I fail too see how t being global vs t being a local that is
doubly passed change anything.
Within
On 3/2/15 4:35 PM, deadalnix wrote:
On Tuesday, 3 March 2015 at 00:11:36 UTC, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 00:02:48 UTC, deadalnix wrote:
What do you think? How many times do you normally pass a global?
I fail too see how t being global vs t being a local that is doubly
On Sunday, 1 March 2015 at 23:56:02 UTC, Zach the Mystic wrote:
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s =
On Monday, 2 March 2015 at 20:04:49 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 13:30:39 UTC, Zach the Mystic wrote:
On Monday, 2 March 2015 at 08:59:11 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 00:37:05 UTC, Zach the Mystic
wrote:
I'm sure many inc/dec can still be removed.
Do
On Monday, 2 March 2015 at 20:36:53 UTC, Marc Schütz wrote:
Interesting approach. I will have to think about that. But I
think it does not really work. Your example hides the fact that
there are actually two types involved (or can be): an RC
wrapper, and the actual class. foo() would need to
On Monday, 2 March 2015 at 08:59:11 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 00:37:05 UTC, Zach the Mystic wrote:
I'm sure many inc/dec can still be removed.
Do you agree or disagree with what I said? I can't tell.
Yes, but I think this is overly conservative.
I'm arguing a rather
On Monday, 2 March 2015 at 00:37:05 UTC, Zach the Mystic wrote:
I'm sure many inc/dec can still be removed.
Do you agree or disagree with what I said? I can't tell.
Yes, but I think this is overly conservative.
On Monday, 2 March 2015 at 13:30:39 UTC, Zach the Mystic wrote:
On Monday, 2 March 2015 at 08:59:11 UTC, deadalnix wrote:
On Monday, 2 March 2015 at 00:37:05 UTC, Zach the Mystic wrote:
I'm sure many inc/dec can still be removed.
Do you agree or disagree with what I said? I can't tell.
On Sunday, 1 March 2015 at 19:35:57 UTC, deadalnix wrote:
On Saturday, 28 February 2015 at 11:12:23 UTC, Marc Schütz
wrote:
Yes. Terminology is a problem here, I guess. When I talk about
the scope of a variable, it means that only references to
values can be stored there whose lifetimes are at
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s = S(RC!T()); // `s.t`'s refcount is 1
T t = s.t;
On Monday, 2 March 2015 at 00:06:52 UTC, deadalnix wrote:
On Sunday, 1 March 2015 at 23:56:02 UTC, Zach the Mystic wrote:
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
On Sunday, 1 March 2015 at 23:56:02 UTC, Zach the Mystic wrote:
On Sunday, 1 March 2015 at 14:40:54 UTC, Marc Schütz wrote:
I don't think a callee-based solution can work:
class T {
void doSomething() scope;
}
struct S {
RC!T t;
}
void main() {
auto s =
On Monday, 2 March 2015 at 00:37:05 UTC, Zach the Mystic wrote:
On Monday, 2 March 2015 at 00:06:52 UTC, deadalnix wrote:
I thought of this, and I disagree. The very fact of assigning
to `T t` adds the reference count you need to keep `s.t` from
disintegrating. As soon as you borrow, you
On Sunday, 1 March 2015 at 05:29:19 UTC, Zach the Mystic wrote:
On Saturday, 28 February 2015 at 20:49:22 UTC, Marc Schütz
wrote:
I encountered an ugly problem. Actually, I had already run
into it in my first proposal, but Steven Schveighoffer just
posted about it here, which made me aware
On Saturday, 28 February 2015 at 11:12:23 UTC, Marc Schütz wrote:
Yes. Terminology is a problem here, I guess. When I talk about
the scope of a variable, it means that only references to
values can be stored there whose lifetimes are at least as
large as the scope.
Make sure you explicit
On Friday, 27 February 2015 at 23:37:42 UTC, deadalnix wrote:
On Friday, 27 February 2015 at 23:18:24 UTC, Marc Schütz wrote:
* When a scoped value is stored somewhere, it is then
reachable through the destination. Therefore, assuming the
source's scope is fixed, the destination's scope must
On Saturday, 28 February 2015 at 06:37:40 UTC, Zach the Mystic
wrote:
On Friday, 27 February 2015 at 23:18:24 UTC, Marc Schütz wrote:
I think I have an inference algorithm that works. It can infer
the required scope levels for local variables given the
constraints of function parameters, and
I encountered an ugly problem. Actually, I had already run into
it in my first proposal, but Steven Schveighoffer just posted
about it here, which made me aware again:
http://forum.dlang.org/thread/mcqcor$aa$1...@digitalmars.com#post-mcqk4s:246qb:241:40digitalmars.com
class T {
On Saturday, 28 February 2015 at 11:12:23 UTC, Marc Schütz wrote:
On Friday, 27 February 2015 at 23:37:42 UTC, deadalnix wrote:
You don't cover the lifetime of the address of operation, and
I'm not how this is supposed to work in your proposal.
It was in the examples, but it was wrong. I've
On Saturday, 28 February 2015 at 20:49:22 UTC, Marc Schütz wrote:
Any other ideas and opinions?
I'm a little busy. It'll take me some time. There's a lot going
on in recent days with all these ideas.
On Saturday, 28 February 2015 at 20:49:22 UTC, Marc Schütz wrote:
I encountered an ugly problem. Actually, I had already run into
it in my first proposal, but Steven Schveighoffer just posted
about it here, which made me aware again:
On Friday, 27 February 2015 at 23:18:24 UTC, Marc Schütz wrote:
I think I have an inference algorithm that works. It can infer
the required scope levels for local variables given the
constraints of function parameters, and it can even infer the
annotations for the parameters (in template
I put my own version into the Wiki, building on yours:
http://wiki.dlang.org/User:Schuetzm/scope2
It's quite similar to what you propose (at least as far as I
understand it), and there are a few further user-facing
simplifications, and provisions for backward compatibility. I
intentionally
On Friday, 27 February 2015 at 22:10:11 UTC, Marc Schütz wrote:
I put my own version into the Wiki, building on yours:
http://wiki.dlang.org/User:Schuetzm/scope2
It's quite similar to what you propose (at least as far as I
understand it), and there are a few further user-facing
I think I have an inference algorithm that works. It can infer
the required scope levels for local variables given the
constraints of function parameters, and it can even infer the
annotations for the parameters (in template functions). It can
also cope with local variables that are explicitly
On Friday, 27 February 2015 at 23:18:24 UTC, Marc Schütz wrote:
* When a scoped value is stored somewhere, it is then reachable
through the destination. Therefore, assuming the source's scope
is fixed, the destination's scope must be widened to
accommodate the source's scope.
So, when you
On Friday, 27 February 2015 at 23:05:39 UTC, Zach the Mystic
wrote:
On Friday, 27 February 2015 at 22:10:11 UTC, Marc Schütz wrote:
I put my own version into the Wiki, building on yours:
http://wiki.dlang.org/User:Schuetzm/scope2
It's quite similar to what you propose (at least as far as I
On Thursday, 26 February 2015 at 16:40:27 UTC, Zach the Mystic
wrote:
int r; // declaration scopedepth(0)
void fun(int a /*scopedepth(0)*/) {
int b; // depth(1)
{
int c; // depth(2)
{
int d; // (3)
}
{
int e; // (3)
}
}
int f; // (1)
}
You have element of differing lifetime
On Wednesday, 25 February 2015 at 18:08:55 UTC, deadalnix wrote:
On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the Mystic
wrote:
int r; // declaration scopedepth(0)
void fun(int a /*scopedepth(0)*/) {
int b; // depth(1)
{
int c; // depth(2)
{
int d; // (3)
}
{
On Thursday, 26 February 2015 at 16:42:30 UTC, Zach the Mystic
wrote:
That is, `a` would have such a reference scope is it were a
reference type... :-)
s/is/if/
I seem to be making one more mistake for every mistake I correct.
On Wednesday, 25 February 2015 at 23:33:57 UTC, H. S. Teoh wrote:
On Wed, Feb 25, 2015 at 09:26:31PM +, via Digitalmars-d
wrote:
[...]
On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the
Mystic wrote:
Principle 3: Extra function and parameter attributes are the
tradeoff
for great
On Wednesday, 25 February 2015 at 21:26:33 UTC, Marc Schütz wrote:
IIRC H.S. Teoh suggested a change to the compilation model. I
think he wants to expand the minimal compilation unit to a
library or executable. In that case, inference for all kinds of
attributes will be available in many more
On Thursday, 26 February 2015 at 16:40:27 UTC, Zach the Mystic
wrote:
I'm unclear about what you're saying. Can you give an example
in code?
See below.
That would allow to copy a parameter reference to a global,
which is dead unsafe.
Actually, it's not unsafe, so long as you have the
On Thursday, 26 February 2015 at 17:56:14 UTC, Zach the Mystic
wrote:
On Wednesday, 25 February 2015 at 21:26:33 UTC, Marc Schütz
wrote:
IIRC H.S. Teoh suggested a change to the compilation model. I
think he wants to expand the minimal compilation unit to a
library or executable. In that case,
On Thursday, 26 February 2015 at 20:46:07 UTC, deadalnix wrote:
Consider :
void foo(T** a) {
T** b = a; // OK
T* = ...;
*b = c; // Legal because of your transitive clause,
// but not safe as a can have an
// arbitrary large lifetime.
}
This example's
On Thursday, 26 February 2015 at 22:45:19 UTC, Zach the Mystic
wrote:
I'm starting to see what you mean. I guess it's only applicable
to variables with double (or more) indirections (e.g. T**,
T***, etc.), since only they can lose information with
transitive scopes. Looks like we need a new
On Thursday, 26 February 2015 at 21:33:53 UTC, Marc Schütz wrote:
On Thursday, 26 February 2015 at 17:56:14 UTC, Zach the Mystic
wrote:
On Wednesday, 25 February 2015 at 21:26:33 UTC, Marc Schütz
wrote:
struct A {
B* b;
~this() {
b.doSomething();
}
}
struct B {
void
On Friday, 27 February 2015 at 00:44:21 UTC, deadalnix wrote:
On Thursday, 26 February 2015 at 22:45:19 UTC, Zach the Mystic
wrote:
I'm starting to see what you mean. I guess it's only
applicable to variables with double (or more) indirections
(e.g. T**, T***, etc.), since only they can lose
It is necessary to use lvalue/rvalues, as it is not just
assignment. Passing thing as ref parameter for instance, needs to
follow these rules.
On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the Mystic
wrote:
So what are these bits? Reserve 4 bits for an unsigned integer
(range 0-15) I call scopedepth. Scopedepth is easier for me
to think about than lifetime, of which it is simply the
inverse, with (0) scopedepth being infinite
I didn't yet have much time to look at it closely enough, but
I'll already make some comments.
On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the Mystic
wrote:
Principle 3: Extra function and parameter attributes are the
tradeoff for great memory safety. There is no other way to
On Wed, Feb 25, 2015 at 09:26:31PM +, via Digitalmars-d wrote:
[...]
On Wednesday, 25 February 2015 at 01:12:15 UTC, Zach the Mystic wrote:
Principle 3: Extra function and parameter attributes are the tradeoff
for great memory safety. There is no other way to support both
encapsulation of
So I've been thinking about how to do safety for a while, and
this is how I would do it if I got to start from scratch. I think
it can be harnessed to D, but I'm worried that people will be
confused by it, or that there might be a show-stopping use case I
haven't thought of, or that it is
52 matches
Mail list logo
