On Thursday, 18 August 2016 at 17:05:05 UTC, Dicebot wrote:
On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
That will just leave one hole in conjunction with the @trusted
destructor, which is (presumably) not easy to fix without much
larger changes to the type system, as well as to how container
t
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
- Please submit pull requests to adjust the markdown document
if you want to propose any improvements (mentioning
@WalterBright and @andralex for confirmation).
Not completely through yet, but it looks really promising.
Already made
On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
> That will just leave one hole in conjunction with the @trusted
> destructor, which is (presumably) not easy to fix without much larger
> changes to the type system, as well as to how container types are built.
> It is still vulnerable to artificial shor
On Wed, 17 Aug 2016 13:53:37 +0300, Dicebot wrote:
> On 08/17/2016 04:01 AM, Chris Wright wrote:
>> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
>>> You need to add one more level of indirection for things to start
>>> going complicated.
>>
>> Presumably scope is transitive, so things shoul
On 08/17/2016 04:01 AM, Chris Wright wrote:
> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
>> You need to add one more level of indirection for things to start going
>> complicated.
>
> Presumably scope is transitive, so things shouldn't get horribly complex.
It is not transitive and it is
On 08/17/2016 10:53 AM, Mike wrote:
> On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
>>
>>> If DIP1000 is implemented, it will change that behavior, so the
>>> allocation will instead be on the GC heap, but the compiler will do some
>>> flow-control analysis to prevent escaping
On Wednesday, 17 August 2016 at 07:53:49 UTC, Mike wrote:
Got it! Thank you! But it still appears that what's
illustrated on the deprecations page is not being deprecated.
Mike
I imagine that will change if/when DIP1000 is accepted.
On Wednesday, 17 August 2016 at 07:17:24 UTC, Rory McGuire wrote:
If DIP1000 is implemented, it will change that behavior, so
the
allocation will instead be on the GC heap, but the compiler
will do some
flow-control analysis to prevent escaping references. Is that
right?
Mike
Not corr
On Wed, Aug 17, 2016 at 9:04 AM, Mike via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
>
>
> Or perhaps DIP1000 changes the current behavior of the `scope` storage
> class.
>
> My understanding is that the `scope` storage class currently allocates a
> class on the stack (th
On Wednesday, 17 August 2016 at 07:04:26 UTC, Mike wrote:
Or perhaps DIP1000 changes the current behavior of the `scope`
storage class.
My understanding is that the `scope` storage class currently
allocates a class on the stack (though its usage for this
purpose is deprecated in favor of s
On Wednesday, 17 August 2016 at 06:44:41 UTC, Mike wrote:
On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire
wrote:
Basically DIP1000 makes it so that:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been d
On Wednesday, 17 August 2016 at 04:28:33 UTC, Rory McGuire wrote:
Basically DIP1000 makes it so that:
void main()
{
A obj;
{
scope A a = new A(1);
obj = a;
}
assert(obj.x == 1); // fails, 'a' has been destroyed
}
Will not compile.
Ok, that makes sense. But t
On 17 Aug 2016 04:00, "Mike via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote:
>
>>> Can you please clarify the current implementation `scope`, and what
DIP1000
>>> proposes to change with respect to the
On Wednesday, 17 August 2016 at 01:42:00 UTC, Walter Bright wrote:
Can you please clarify the current implementation `scope`, and
what DIP1000
proposes to change with respect to the current implementation?
It just adds to the existing compiler implementation of
'scope'. It has nothing to do
On 8/16/2016 6:01 PM, H. S. Teoh via Digitalmars-d-announce wrote:
On Wed, Aug 17, 2016 at 01:01:05AM +, Chris Wright via
Digitalmars-d-announce wrote:
On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
You need to add one more level of indirection for things to start
going complicated.
On 8/16/2016 5:31 PM, Mike wrote:
On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote:
On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote:
Does that actually work in D2?
Yes.
Can you please clarify the current implementation `scope`, and what DIP1000
proposes to change with resp
On Wed, Aug 17, 2016 at 01:01:05AM +, Chris Wright via
Digitalmars-d-announce wrote:
> On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
> > You need to add one more level of indirection for things to start
> > going complicated.
>
> Presumably scope is transitive, so things shouldn't get ho
On Tue, 16 Aug 2016 18:55:40 +, Dicebot wrote:
> You need to add one more level of indirection for things to start going
> complicated.
Presumably scope is transitive, so things shouldn't get horribly complex.
On Monday, 15 August 2016 at 04:58:06 UTC, Walter Bright wrote:
On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote:
Does that actually work in D2?
Yes.
Can you please clarify the current implementation `scope`, and
what DIP1000 proposes to change with respect to the current
implementation
On 8/16/2016 11:25 AM, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
'state' is set to null by 'new Rnd()', and so no pointers escape.
On 16 Aug 2016 21:01, "Dicebot via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote:
>>
>> On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
>>>
>>> What about this?
>>>
>>> struct Rnd
>>> {
>>> int* state
On Tuesday, 16 August 2016 at 18:55:40 UTC, Dicebot wrote:
On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Same as far as I understand, because
On Tuesday, 16 August 2016 at 18:25:42 UTC, Meta wrote:
What about this?
struct Rnd
{
int* state;
}
void test()
{
scope rnd = new Rnd();
Rnd rnd2 = *rnd;
saveGlobalState(rnd2);
}
Same as far as I understand, because "from a lifetime analysis
viewpoint, a struct is considered
On Tuesday, 16 August 2016 at 16:34:05 UTC, Dicebot wrote:
On 08/16/2016 07:26 PM, Patrick Schluter wrote:
What happens in that case ?
void test() {
scope rnd = new Rnd; // reference semantic and stack allocated
Rnd rnd2;
rnd2 = rnd;
some_sneaky_function_that_saves_global_state(rnd);
On 08/16/2016 07:26 PM, Patrick Schluter wrote:
> What happens in that case ?
>
> void test() {
> scope rnd = new Rnd; // reference semantic and stack allocated
> Rnd rnd2;
> rnd2 = rnd;
> some_sneaky_function_that_saves_global_state(rnd);
> }
>
> or is that not even possible ? (sorry
On Monday, 15 August 2016 at 21:25:22 UTC, Walter Bright wrote:
On 8/15/2016 6:54 AM, Rory McGuire via Digitalmars-d-announce
wrote:
okay nice, so that code would not compile but code such as:
void test() {
scope rnd = new Rnd; // reference semantic and stack allocated
auto rnd2 = rnd;
On 8/15/2016 6:54 AM, Rory McGuire via Digitalmars-d-announce wrote:
okay nice, so that code would not compile but code such as:
void test() {
scope rnd = new Rnd; // reference semantic and stack allocated
auto rnd2 = rnd;
some_sneaky_function_that_saves_global_state(rnd);
}
would still
On Mon, Aug 15, 2016 at 4:05 PM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 08/15/2016 04:54 PM, Rory McGuire via Digitalmars-d-announce wrote:
> > okay nice, so that code would not compile but code such as:
> > void test() {
> > scope rnd = new Rnd; //
On 08/15/2016 04:54 PM, Rory McGuire via Digitalmars-d-announce wrote:
> okay nice, so that code would not compile but code such as:
> void test() {
> scope rnd = new Rnd; // reference semantic and stack allocated
> auto rnd2 = rnd;
> some_sneaky_function_that_saves_global_state(rnd);
> }
On Mon, Aug 15, 2016 at 2:49 PM, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 08/15/2016 03:41 PM, Rory McGuire via Digitalmars-d-announce wrote:
> > scope rnd = new Rnd; // reference semantic and stack allocated
> > auto rnd2 = rnd;
> >
> > rnd.i = 2;
>
On 08/15/2016 03:41 PM, Rory McGuire via Digitalmars-d-announce wrote:
> scope rnd = new Rnd; // reference semantic and stack allocated
> auto rnd2 = rnd;
>
> rnd.i = 2;
> assert(rnd2.i == 2);
> return rnd2;
Point is that that would become illegal if DIP1000 is implemented thus
giving scope clas
On Mon, Aug 15, 2016 at 1:57 PM, ZombineDev via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 15 August 2016 at 10:27:00 UTC, Dicebot wrote:
>
>> On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote:
>>
>>> When was it deprecated? I use it a lot and DMD 2.071.
On Monday, 15 August 2016 at 10:27:00 UTC, Dicebot wrote:
On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote:
When was it deprecated? I use it a lot and DMD 2.071.1 gives
no warning.
It was planned for removal because it was very un-@safe (no
escaping checks whatsoever) and as such was not
On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote:
When was it deprecated? I use it a lot and DMD 2.071.1 gives no
warning.
It was planned for removal because it was very un-@safe (no
escaping checks whatsoever) and as such was not better than
library implementation. Quite likely with DIP
On Monday, 15 August 2016 at 07:19:00 UTC, lobo wrote:
On Monday, 15 August 2016 at 07:10:00 UTC, ZombineDev wrote:
On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton
Wakeling wrote:
On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet
wrote:
Isn't it what a scoped class is sup
On Monday, 15 August 2016 at 07:10:00 UTC, ZombineDev wrote:
On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton
Wakeling wrote:
On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet
wrote:
Isn't it what a scoped class is supposed to provide?
class Rnd {}
void foo() {
scope rn
On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton
Wakeling wrote:
On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet
wrote:
Isn't it what a scoped class is supposed to provide?
class Rnd {}
void foo() {
scope rnd = new Rnd; // reference semantic and stack
allocated
}
On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote:
Does that actually work in D2?
Yes.
On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet
wrote:
Isn't it what a scoped class is supposed to provide?
class Rnd {}
void foo() {
scope rnd = new Rnd; // reference semantic and stack
allocated
}
Does that actually work in D2? I thought it was a D1-only thing.
On Saturday, 13 August 2016 at 20:50:53 UTC, Joseph Rushton
Wakeling wrote:
The TL;DR here is that I'm concerned about having a solution
for random number generators and random algorithms that (i)
allows them to be stack-allocated, (ii) ensures that their
internal state is not accidentally copi
On 8/13/2016 1:50 PM, Joseph Rushton Wakeling wrote:
Sure, but doesn't the envisioned DIP create the circumstances in which it could
also be permitted in @safe code where the compiler can guarantee that the
pointer's lifetime will not outlive the data referred to?
The whole point of ref is that
On Saturday, 13 August 2016 at 19:51:07 UTC, Walter Bright wrote:
On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote:
On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright
wrote:
Taking the address of a ref variable has not been allowed in
@safe code for a
long time.
Which is understan
On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote:
On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote:
Taking the address of a ref variable has not been allowed in @safe code for a
long time.
Which is understandable given things as they are, but which could probably be
relaxed
On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote:
Taking the address of a ref variable has not been allowed in
@safe code for a long time.
Which is understandable given things as they are, but which could
probably be relaxed given good scope/lifetime analysis by the
compiler..
On 8/13/2016 1:13 AM, Joseph Rushton Wakeling wrote:
On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote:
That's just what this DIP addresses.
struct MyWrapperStruct (T)
{
private T* data;
public this (ref T input)
{
this.data = &input; //
On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote:
That's just what this DIP addresses.
struct MyWrapperStruct (T)
{
private T* data;
public this (ref T input)
{
this.data = &input; // error: not allowed to take
address of ref variable
On 8/12/2016 1:08 PM, Timon Gehr wrote:
On 12.08.2016 21:39, Walter Bright wrote:
On 8/12/2016 5:33 AM, Nordlöw wrote:
If this is successfully implemented, what will D not be able to do,
that Rust
can/will?
Have ownership semantics for pointers in more complex data structures.
In D you'll hav
On 12.08.2016 21:39, Walter Bright wrote:
On 8/12/2016 5:33 AM, Nordlöw wrote:
If this is successfully implemented, what will D not be able to do,
that Rust
can/will?
Have ownership semantics for pointers in more complex data structures.
In D you'll have to do such with ref counted objects.
O
On 8/12/2016 5:24 AM, Nordlöw wrote:
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it bypasses usual nitpicking process and proceeds
straight to requesting community (your!) feedback.
On 8/12/2016 12:03 PM, Timon Gehr wrote:
On 11.08.2016 09:48, Walter Bright wrote:
On 8/10/2016 11:36 PM, rikki cattermole wrote:
Perfect :)
The nice thing about this scheme is it can do some things that Rust
can't
What are some of those things?
Accessing mutable globals in a function com
On 8/12/2016 5:33 AM, Nordlöw wrote:
If this is successfully implemented, what will D not be able to do, that Rust
can/will?
Have ownership semantics for pointers in more complex data structures. In D
you'll have to do such with ref counted objects.
On the other hand, D code can reference mu
On 8/12/2016 5:54 AM, Joseph Rushton Wakeling wrote:
On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton Wakeling wrote:
I'm not sure I follow. I'm looking for the ability to guarantee that a
pointer to a stack-allocated entity will not go out of scope
... more precisely, that the point
On 11.08.2016 09:48, Walter Bright wrote:
On 8/10/2016 11:36 PM, rikki cattermole wrote:
Perfect :)
The nice thing about this scheme is it can do some things that Rust
can't
What are some of those things?
On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton
Wakeling wrote:
I'm not sure I follow. I'm looking for the ability to
guarantee that a pointer to a stack-allocated entity will not
go out of scope
... more precisely, that the pointer will not become invalid
because the data it point
On Friday, 12 August 2016 at 12:01:41 UTC, Walter Bright wrote:
On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote:
On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright
wrote:
The scheme does not implement borrowing. References to
internal data should be
returned via 'return ref' or 'ret
On Thursday, 11 August 2016 at 07:48:18 UTC, Walter Bright wrote:
On 8/10/2016 11:36 PM, rikki cattermole wrote:
Perfect :)
The nice thing about this scheme is it can do some things that
Rust can't (and Rust can do things that this can't). I suppose
it will balance out.
If this is successf
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it bypasses usual
nitpicking process and proceeds straight to requesting
community (your!) feedback.
Thanks for all the work.
One rem
On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote:
On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote:
The scheme does not implement borrowing. References to internal data should be
returned via 'return ref' or 'return scope', where their usage will be limited
to the expression t
On Thursday, 11 August 2016 at 22:03:02 UTC, Walter Bright wrote:
On 8/11/2016 6:38 AM, Sönke Ludwig wrote:
What would be nice to add is a behavior specification for
'scope' member
variables (lifetime considered equal or slightly shorter than
parent object
lifetime). For example the `RefCounted
On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote:
The scheme does not implement borrowing. References to internal
data should be returned via 'return ref' or 'return scope',
where their usage will be limited to the expression they appear
in.
I want to make sure we have the sam
On 8/11/2016 12:59 PM, Joseph Rushton Wakeling wrote:
There's a use-case that relates to some of our discussions together in another
context, about structs or classes that borrow data via ref:
The scheme does not implement borrowing. References to internal data should be
returned via 'return r
On 8/11/2016 6:38 AM, Sönke Ludwig wrote:
What would be nice to add is a behavior specification for 'scope' member
variables (lifetime considered equal or slightly shorter than parent object
lifetime). For example the `RefCountedSlice.payload` and `count` fields could be
annotated with 'scope' to
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
The first DIP has just landed into the new queue. It is a (...)
The wording is unclear in the section "Implicit Conversion of
Function Pointers and Delegates".
It says "scope can be added to parameters, but not removed."
The troub
On Wed, Aug 10, 2016 at 08:35:23PM +, Dicebot via Digitalmars-d-announce
wrote:
> The first DIP has just landed into the new queue. It is a proposal from
> language authors and thus it bypasses usual nitpicking process and proceeds
> straight to requesting community (your!) feedback.
>
> Esse
On Thursday, 11 August 2016 at 19:59:22 UTC, Joseph Rushton
Wakeling wrote:
Any chance the proposal authors could add some examples of how
scope could affect class/struct fields which borrow data by
reference (meaning the class/struct instance should not escape
the scope of the input data)?
S
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
- At this point the question I'd personally suggest to be
evaluated is "does this proposal enable enough useful
designs?". A good check would be to try taking some of your
projects and see if having DIP1000 approved and implemented
c
This looks like the best proposal so far. Many useful ideas, and at the
first glance it looks like a big step forward. I also really like how
the useful stack allocation behavior for closures and new'ed values is
kept alive.
What would be nice to add is a behavior specification for 'scope' mem
On 8/10/2016 11:36 PM, rikki cattermole wrote:
Perfect :)
The nice thing about this scheme is it can do some things that Rust can't (and
Rust can do things that this can't). I suppose it will balance out.
On 11/08/2016 5:41 PM, Walter Bright wrote:
On 8/10/2016 10:05 PM, rikki cattermole wrote:
Question:
I see RefCountedSlice example, does this mean if I alias this say like:
struct FooBar;
struct Foo {
FooBar* v;
scope FooBar* get() { return v; }
alias this get;
}
That it will ope
On 8/10/2016 10:05 PM, rikki cattermole wrote:
Question:
I see RefCountedSlice example, does this mean if I alias this say like:
struct FooBar;
struct Foo {
FooBar* v;
scope FooBar* get() { return v; }
alias this get;
}
That it will operate correctly in the below case?
func(myFoo
This bit seems odd:
T func(T* t) {
return t; // ok
}
Is there an implicit conversion from T* to T?
On Wed, Aug 10, 2016 at 10:05 PM, rikki cattermole via
Digitalmars-d-announce wrote:
> On 11/08/2016 8:35 AM, Dicebot wrote:
>
>> The first DIP has just landed into the new queue. It is a prop
On 11/08/2016 8:35 AM, Dicebot wrote:
The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it bypasses usual nitpicking process and
proceeds straight to requesting community (your!) feedback.
Essentially, it is an attempt to solve reference lifetime p
On 8/10/2016 4:56 PM, Nicholas Wilson wrote:
How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant]
interact with LDC's GC to stack promotion pass?
I don't know about how that works in LDC, but general such a promotion can only
be done if the compiler can prove there are no
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it bypasses usual
nitpicking process and proceeds straight to requesting
community (your!) feedback.
[...]
How will the infinite lif
The first DIP has just landed into the new queue. It is a
proposal from language authors and thus it bypasses usual
nitpicking process and proceeds straight to requesting community
(your!) feedback.
Essentially, it is an attempt to solve reference lifetime problem
by extending implementation
75 matches
Mail list logo