On Tuesday, 27 October 2015 at 18:10:18 UTC, deadalnix wrote:
I've made the claim that we should implement reference counting
as a library many time, so I think I should explicit my
position. Indeed, RC require some level a compiler support to
be safe. That being said, the support does not
Please scan this thread for any useful ideas:
http://forum.dlang.org/post/vlzwhhymkjgckgyox...@forum.dlang.org
I don't have the technical expertise to know if it's useful or
could work. The basic suggestion is that D has a function
attribute which expressly indicates that a function is
On Wednesday, 18 March 2015 at 09:28:35 UTC, deadalnix wrote:
On Wednesday, 18 March 2015 at 06:24:38 UTC, Zach the Mystic
wrote:
I'm starting to think that refcounting is precisely the
opposite of ownership, useful only for when its *impossible*
to track ownership easily. Otherwise why would
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 Wednesday, 18 March 2015 at 03:45:07 UTC, Walter Bright wrote:
The bad news: the Phobos documentation sux.
The good news: we can make things a lot better by just filling
in blanks. For example, picking a function largely at random:
http://dlang.org/phobos/std_uni.html#sicmp
There is no
On Wednesday, 18 March 2015 at 20:19:10 UTC, Walter Bright wrote:
On 3/18/2015 12:42 PM, Zach the Mystic wrote:
But why, therefore, is it so hard to get movement on it?
I don't know why, so I'll ask. Why haven't you submitted a PR
to fix one of them? :-)
I have pathetically little
On Wednesday, 18 March 2015 at 18:09:07 UTC, Walter Bright wrote:
On 3/18/2015 10:55 AM, Zach the Mystic wrote:
No responses yet -- not that I'm any less guilty than anyone
else. But maybe
this needs to be bumped up to a higher priority -- a hiatus on
internal
development for a couple weeks
On Wednesday, 18 March 2015 at 19:50:24 UTC, Andrei Alexandrescu
wrote:
On 3/18/15 12:42 PM, Zach the Mystic wrote:
At some point, it must be possible for documentation to get so
bad that
*nothing* is more important.
Strategically we're definitely there, and have been for a while
(if we
On Tuesday, 17 March 2015 at 22:53:20 UTC, deadalnix wrote:
On Tuesday, 17 March 2015 at 22:25:30 UTC, Zach the Mystic
wrote:
The real devil against safe reference counting is in the
assignment operators, when they do destructive moves. I think
those have to be the focus of any effort here.
On Tuesday, 17 March 2015 at 18:27:01 UTC, ixid wrote:
To be fully viable, `return` would have to be secretly
recorded as part of the `x's type, so that the compiler could
forgive returning it to a non-const. But the compiler should
probably track that `x` is copied from `t` anyway, so that it
On Tuesday, 17 March 2015 at 19:53:14 UTC, deadalnix wrote:
On Tuesday, 17 March 2015 at 13:55:36 UTC, Dejan Lekic wrote:
I definitely think this is a good idea. And if someone wants
mutable variable, we simply use proposed 'var' storage class.
Brilliant!
This is going to break pretty much
On Tuesday, 17 March 2015 at 12:02:15 UTC, Nick Treleaven wrote:
On 16/03/2015 14:17, Zach the Mystic wrote:
char* fun(return const char* x);
Compiler has enough information to adjust the return type of
`fun()` to
that of input `x`. This assumes return parameters have been
generalized
to
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 19:52:00 UTC, deadalnix wrote:
On Monday, 16 March 2015 at 14:40:51 UTC, Zach the Mystic wrote:
On Sunday, 15 March 2015 at 20:09:56 UTC, deadalnix wrote:
On Sunday, 15 March 2015 at 07:44:50 UTC, Walter Bright wrote:
const ref can tell the optimizer that that path
char* fun(return const char* x);
Compiler has enough information to adjust the return type of
`fun()` to that of input `x`. This assumes return parameters have
been generalized to all reference types. Destroy.
On Sunday, 15 March 2015 at 20:09:56 UTC, deadalnix wrote:
On Sunday, 15 March 2015 at 07:44:50 UTC, Walter Bright wrote:
const ref can tell the optimizer that that path for a ref
counted object cannot alter its ref count.
That is not clear why. const ref is supposed to protect against
On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote:
On Mon, 16 Mar 2015 14:17:57 +, Zach the Mystic wrote:
char* fun(return const char* x);
Compiler has enough information to adjust the return type of
`fun()` to
that of input `x`. This assumes return parameters have been
generalized
On Monday, 16 March 2015 at 15:39:39 UTC, ketmar wrote:
On Mon, 16 Mar 2015 15:33:40 +, Zach the Mystic wrote:
On Monday, 16 March 2015 at 14:23:42 UTC, ketmar wrote:
On Mon, 16 Mar 2015 14:17:57 +, Zach the Mystic wrote:
char* fun(return const char* x);
Compiler has enough
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 16:49:36 UTC, ketmar wrote:
having argument modifier that changes function return type is
very
surprising regardless of how much people used to it. really,
why should i
parse *arguments* to know the (explicitly specified!) *return*
*type*?
it's ok with `auto`, it's
On Monday, 16 March 2015 at 16:22:46 UTC, Marc Schütz wrote:
On Monday, 16 March 2015 at 14:17:58 UTC, Zach the Mystic wrote:
char* fun(return const char* x);
Compiler has enough information to adjust the return type of
`fun()` to that of input `x`. This assumes return parameters
have been
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
On Monday, 16 March 2015 at 00:27:56 UTC, Walter Bright wrote:
I like the analogy of D being a fully equipped machine shop, as
opposed to a collection of basic hand tools.
When I was younger it was hard working on my car, because I
could not afford the right tools. So I made do with whatever
On Saturday, 14 March 2015 at 15:55:51 UTC, Marc Schütz wrote:
Are the suggested changes also related to the possibility of
making `ref` a type?
Are there plans to do this? I remember Walter suggested `ref`
for non-parameters, i.e. local variables, but as a storage
class, not a type
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 Wednesday, 11 March 2015 at 20:33:07 UTC, Andrei Alexandrescu
wrote:
I'm investigating D's ability to define and use smart
references. Per the skeleton at
http://dpaste.dzfl.pl/9d752b1e9b4e, lines:
#6: You can't default-initialize a ref.
#7: You can't copy a ref - copying should mean
On Friday, 6 March 2015 at 14:40:31 UTC, Volodymyr wrote:
On Friday, 6 March 2015 at 07:46:13 UTC, Zach the Mystic wrote:
...
Note how the last member, opIndex, doesn't return a raw E*,
but only an E* which is paired with a pointer to the same
RCData instance as the RCArray is:
struct
On Friday, 6 March 2015 at 14:59:46 UTC, monarch_dodra wrote:
struct RCArray(E) {
E[] array;
int* count;
...
}
auto x = RCArray([E()]);
E* t = x[0];
But taking that address is unsafe to begin with. Do arguably,
this isn't that big of a problem.
Taking the address is only really unsafe
On Thursday, 5 March 2015 at 18:41:31 UTC, deadalnix wrote:
Kind of OT, but your train of thought is very difficult to
follow the way you are communicating (ie by updating on
previous post by answering to yourself).
Could you post some more global overview at some point, so one
does not need
On Wednesday, 4 March 2015 at 18:05:52 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 17:22:15 UTC, Steven
Schveighoffer wrote:
Again, I think this is an issue with the expectation of
RCArray. You cannot *save* a ref to an array element, only a
ref to the array itself, because you
As per deadalnix's request, a summary of my thoughts regarding
the thread RCArray is unsafe:
It's rather easy to guarantee memory safety from the safe
confines of a garbage collected system. Let's take this as a
given.
It's much harder when you step outside that system and try to
figure
On Wednesday, 4 March 2015 at 17:13:13 UTC, Zach the Mystic wrote:
(Also, `pure` functions will need no `static` parameter
attributes, and functions both `pure` and `@nogc` will not need
)
...will not need `@noscope` either.
On Wednesday, 4 March 2015 at 09:06:01 UTC, Walter Bright wrote:
On 3/4/2015 12:13 AM, deadalnix wrote:
The #1 argument for DIP25 compared to alternative proposal was
its simplicity. I
assume at this point that we have empirical evidence that this
is NOT the case.
The complexity of a free
On Wednesday, 4 March 2015 at 07:50:50 UTC, Manu wrote:
Well you can't get to a subcomponent if not through it's owner.
If the question is about passing RC objects members to
functions, then
the solution is the same as above, the stack needs a reference
to the
parent before it can pass a
On Wednesday, 4 March 2015 at 08:13:33 UTC, deadalnix wrote:
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic
wrote:
That's fine. I like DIP25. It's a start towards stronger
safety guarantees. While I'm pretty sure the runtime costs of
my proposal are lower than yours, they do
On Wednesday, 4 March 2015 at 08:13:33 UTC, deadalnix wrote:
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic
wrote:
That's fine. I like DIP25. It's a start towards stronger
safety guarantees. While I'm pretty sure the runtime costs of
my proposal are lower than yours, they do
On Wednesday, 4 March 2015 at 17:22:15 UTC, Steven Schveighoffer
wrote:
Again, I think this is an issue with the expectation of
RCArray. You cannot *save* a ref to an array element, only a
ref to the array itself, because you lose control over the
reference count.
What you need is a special
On Wednesday, 4 March 2015 at 18:05:52 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 17:22:15 UTC, Steven
Schveighoffer wrote:
Again, I think this is an issue with the expectation of
RCArray. You cannot *save* a ref to an array element, only a
ref to the array itself, because you
On Wednesday, 4 March 2015 at 18:17:41 UTC, Andrei Alexandrescu
wrote:
Yah, this is a fork in the road: either we solve this with
DIP25 + implementation, or we add stricter static checking
disallowing two lent references to data in the same scope.
The third solution is to keep track of
On Wednesday, 4 March 2015 at 17:13:13 UTC, Zach the Mystic wrote:
Another example:
T* jun(return static T* a) {
static T* t;
t = a;
return a;
}
Again, no ownership, because of the `static` parameter
attribute. In a previous post, you suggested that such an
attribute was unnecessary,
On Wednesday, 4 March 2015 at 19:22:25 UTC, Zach the Mystic wrote:
On Wednesday, 4 March 2015 at 18:17:41 UTC, Andrei Alexandrescu
wrote:
Yah, this is a fork in the road: either we solve this with
DIP25 + implementation, or we add stricter static checking
disallowing two lent references to
On Tuesday, 3 March 2015 at 05:12:15 UTC, Walter Bright wrote:
On 3/2/2015 6:04 PM, weaselcat wrote:
On Tuesday, 3 March 2015 at 01:56:09 UTC, Walter Bright wrote:
On 3/2/2015 4:40 PM, deadalnix wrote:
After moving resources, the previous owner can no longer be
used.
How does that work with
On Tuesday, 3 March 2015 at 08:04:25 UTC, Manu wrote:
My immediate impression on this problem:
s.array[0] is being passed to foo from main. s does not belong
to main
(is global), and main does not hold have a reference to s.array.
Shouldn't main just need to inc/dec array around the call to
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
Pretty dazz idea, dontcha think? And DIP25 still stands
unscathed :-)
Unless, of course, we missed something obvious.
I was dazzed, but I'm not anymore. I wrote my concern here:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
http://forum.dlang.org/post/ylpaqhnuiczfgfpqj...@forum.dlang.org
There's a misunderstanding here. The object being assigned
keeps a trailing list of past values
On Tuesday, 3 March 2015 at 17:40:59 UTC, Marc Schütz wrote:
All instances need to carry a pointer to refcount anyway, so
the freelist could just be stored next to the refcount. The
idea of creating that list, however, is more worrying, because
it again involves allocations. It can get
On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 9:00 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
On Wednesday, 4 March 2015 at 03:46:36 UTC, Zach the Mystic wrote:
Just my own past posts. My suggestion is based on the compiler
doing all the work. I don't know how it could be tested without
hacking the compiler.
I think that part of the fear of my idea is that I want structs
to get some
On Tuesday, 3 March 2015 at 21:37:20 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 12:35 PM, Zach the Mystic wrote:
Isn't allocating and collecting a freelist also overhead?
No. I don't have time now for a proof of concept and it seems
everybody wants to hypothesize about code that doesn't exist
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:54:20 UTC, Walter Bright wrote:
On 3/2/2015 12:42 PM, Walter Bright wrote:
For D structs, that means, if there's a postblit, a copy must
be made. For D ref counted classes, a ref count increment must
be done.
I was hoping to avoid that, but apparently there's no
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 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 20:37:46 UTC, Walter Bright wrote:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to
global variables too:
S s;
void main() {
s.array = RCArray!T([T()]); // s.array's refcount is
now 1
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 Tuesday, 3 March 2015 at 01:23:24 UTC, Zach the Mystic wrote:
Which makes me think about a bigger problem... when you
opAssign, don't you redirect the variable to a different
instance? Won't the destructor then destroy *that* instance (or
not destroy it, since it just got a +1 count)
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
His insight was that the deletion of the payload occurred
before the end of the lifetime of the RC object, and that this
was the source of the problem. If the deletion of the payload
occurs during the destructor call, rather than
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
I.e. the postblit manipulates the ref count, but does NOT do
payload deletions. The destructor checks the ref count, if it
is zero, THEN it does the payload deletion.
Pretty dazz idea, dontcha think? And DIP25 still stands
On Monday, 2 March 2015 at 22:58:19 UTC, Walter Bright wrote:
His insight was that the deletion of the payload occurred
before the end of the lifetime of the RC object, and that this
was the source of the problem. If the deletion of the payload
occurs during the destructor call, rather than
On Tuesday, 3 March 2015 at 00:05:50 UTC, Zach the Mystic wrote:
I guess you also mean opAssigns -- they would manipulate
refcounts too right? In fact, they would be the primary means
of decrementing the refcount *apart* from the destructor, right?
Nevermind. I was a minute too soon with my
On Monday, 2 March 2015 at 05:57:35 UTC, Walter Bright wrote:
On 3/1/2015 12:51 PM, Michel Fortin wrote:
That's actually not enough. You'll have to block access to
global variables too:
Hmm. That's not so easy to solve.
But consider this. It's only an impure function which might alias
a
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 Sunday, 1 March 2015 at 20:51:35 UTC, Michel Fortin wrote:
On 2015-03-01 19:21:57 +, Walter Bright said:
The trouble seems to happen when there are two references to
the same object passed to a function. I.e. there can be only
one borrowed ref at a time.
I'm thinking this could be
On Monday, 2 March 2015 at 15:22:33 UTC, Zach the Mystic wrote:
void fun() {
T[] ta = [T()].dup;
T* t = ta[0];
I meant: T* t = ta[0];
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 Saturday, 28 February 2015 at 23:03:23 UTC, Walter Bright
wrote:
On 2/28/2015 2:31 AM, bearophile wrote:
Zach the Mystic:
You can see exactly how D works by looking at how Kenji
spends his time. For a
while he's only been fixing ICEs and other little bugs which
he knows for
certain will
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 11:30:52 UTC, bearophile wrote:
Walter Bright:
Actually, Kenji fearlessly deals with some of the hardest bugs
in the compiler that require a deep understanding of how the
compiler works and how it is supposed to work. He rarely does
trivia. I regard Kenji's
On Sunday, 1 March 2015 at 20:51:35 UTC, Michel Fortin wrote:
On 2015-03-01 19:21:57 +, Walter Bright said:
The trouble seems to happen when there are two references to
the same object passed to a function. I.e. there can be only
one borrowed ref at a time.
I'm thinking this could be
On Sunday, 1 March 2015 at 15:44:49 UTC, Marc Schütz wrote:
Walter posted an example implementation of a reference counted
array [1], that utilizes the features introduced in DIP25 [2].
Then, in the threads about reference counted objects, several
people posted examples [3, 4] that broke the
On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu
wrote:
Tracing garbage collection can afford the luxury of e.g.
mutating data that was immutable during its lifetime.
Reference counting needs to make minute mutations to data while
references to that data are created. In fact, it's
On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
class RcType {...}
void fun(RcType1 c, RcType1 d);
auto x = new RcType;
fun(x, x);
If the compiler were smart, it would realize that by splitting
parameters this way, it's actually adding an additional
reference to x. The
On Friday, 27 February 2015 at 21:21:08 UTC, Andrei Alexandrescu
wrote:
On 2/27/15 1:02 PM, Michel Fortin wrote:
On 2015-02-27 20:34:08 +, Steven Schveighoffer said:
void main()
{
C2 c2 = new C2;
c2.c = new C;
foo(c2.c, c2);
}
Still same question. The issue here is how do you
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 21:12:54 UTC, Andrei
Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
This is obviously much better, Andrei.
I think an alternative solution (I know -- another idea --
against my own first idea!)
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
On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei
Alexandrescu wrote:
http://wiki.dlang.org/DIP74 got to reviewable form. Please
destroy and discuss.
Thanks,
Andrei
It's kind of funny that you were looking for an edge to my safety
system -- I'll admit I don't know whether it really has
On Friday, 27 February 2015 at 14:02:58 UTC, Andrei Alexandrescu
wrote:
Safety is good to have, and the simple litmus test is if you
slap @safe: at the top of all modules and you use no @trusted
(or of course use it correctly), you should have memory safety,
guaranteed.
A feature that is
On Friday, 27 February 2015 at 18:24:27 UTC, Andrei Alexandrescu
wrote:
DIP74's function call protocol for RCOs has the caller insert
opAddRef for each RCO passed by value. Then the callee has the
responsibility to call opRelease (or defer that to another
entity). This choice of protocol
On Friday, 27 February 2015 at 15:35:46 UTC, H. S. Teoh wrote:
@safe has some pretty nasty holes right now... like:
https://issues.dlang.org/show_bug.cgi?id=5270
https://issues.dlang.org/show_bug.cgi?id=8838
My new reference safety system:
On Friday, 27 February 2015 at 20:30:20 UTC, Steven Schveighoffer
wrote:
OK, I found the offending issue. It's when you pass a
parameter, the only reference holding onto it may be also
passed as well. Something like:
void foo(C c, C2 c2)
{
c2.c = null; // this destroys 'c' unless you
On Friday, 27 February 2015 at 21:21:08 UTC, Andrei Alexandrescu
wrote:
On 2/27/15 1:02 PM, Michel Fortin wrote:
On 2015-02-27 20:34:08 +, Steven Schveighoffer said:
On 2/27/15 3:30 PM, Steven Schveighoffer wrote:
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; //
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
On Friday, 27 February 2015 at 21:09:51 UTC, H. S. Teoh wrote:
https://issues.dlang.org/show_bug.cgi?id=12822
https://issues.dlang.org/show_bug.cgi?id=13442
https://issues.dlang.org/show_bug.cgi?id=13534
https://issues.dlang.org/show_bug.cgi?id=13536
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 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
Here's my best so far:
http://forum.dlang.org/post/offurllmuxjewizxe...@forum.dlang.org
On Tuesday, 24 February 2015 at 20:53:24 UTC, Walter Bright wrote:
My criticisms of it centered around:
1. confusion about whether it was a storage class or a type
qualifier.
My system has neither.
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 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
On Friday, 27 February 2015 at 01:33:58 UTC, Jonathan M Davis
wrote:
Well, I suspect that each case would have to be examined
individually to
decide upon the best action, but I think that what it comes
down to is the
same problem that we have with getting anything done around
here - someone
On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu
wrote:
I'm following with interest the discussion My Reference Safety
System (DIP???). Right now it looks like a lot of work - a
long opener, subsequent refinements, good discussion. It also
seems just that - there's work but
On Tuesday, 24 February 2015 at 12:44:54 UTC, Marc Schütz wrote:
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei
Alexandrescu wrote:
On 2/23/15 6:56 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
These two points have undesirable consequences: All consumers
such
objects need to
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
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
Wait a second... you're totally right. That is a cool solution.
The only hiccup is that it might be hard to implement in the
compiler because of flow tracking (i.e. the error comes before
the @system block, forcing a recheck
On Tuesday, 10 February 2015 at 16:04:05 UTC, Marc Schütz wrote:
On Tuesday, 10 February 2015 at 15:57:28 UTC, Zach the Mystic
wrote:
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
As already pointed out in the other thread, there is a
non-breaking variant of (3):
3a.
1 - 100 of 245 matches
Mail list logo
