Jump to page: 1 2 3
Thread overview
@live questions
3 days ago
Max Haughton
3 days ago
Timon Gehr
3 days ago
Walter Bright
3 days ago
jmh530
3 days ago
Timon Gehr
3 days ago
Timon Gehr
2 days ago
thedeemon
2 days ago
Timon Gehr
2 days ago
thedeemon
3 days ago
Walter Bright
12 hours ago
Walter Bright
12 hours ago
Walter Bright
3 days ago
ag0aep6g
12 hours ago
Walter Bright
3 days ago
Timon Gehr
2 days ago
IGotD-
12 hours ago
Walter Bright
11 hours ago
IGotD-
3 days ago
Hi

I don't quite know Rust so it is bit hard to compare this feature with Rust. Ideally someone who knows both languages in depth should compare and figure out if @live is comparable to Rust ownership ideas.

I have following questions / suggestions:

a) I understand on its own @live is only part of what Rust does? Rust has lifetime annotations and I believe it can track memory allocation across a graph of objects and ensure there is no leak etc. Is my understanding correct that @live only deals with pointers and to compare this to Rust, one has to also include DIP1000?

My first suggestion is that @live and DIP1000 features should be documented together. I heard in the discussions that DIP1000 is actually not yet documented?

b) Is it also the case that DIP1000 is only available if a function is marked @safe?

It seems to me that both @live and @safe should be available as compiler flags to turn them on - and not have to rely on annotations. Is this possible? Certainly in Laser-D I would like these to be ON by default and annotation should be to suppress rather than enable.
3 days ago
On Sunday, 22 November 2020 at 02:28:20 UTC, Dibyendu Majumdar wrote:
> Hi
>
> I don't quite know Rust so it is bit hard to compare this feature with Rust. Ideally someone who knows both languages in depth should compare and figure out if @live is comparable to Rust ownership ideas.
>
> I have following questions / suggestions:
>
> a) I understand on its own @live is only part of what Rust does? Rust has lifetime annotations and I believe it can track memory allocation across a graph of objects and ensure there is no leak etc. Is my understanding correct that @live only deals with pointers and to compare this to Rust, one has to also include DIP1000?
>
> My first suggestion is that @live and DIP1000 features should be documented together. I heard in the discussions that DIP1000 is actually not yet documented?
>
> b) Is it also the case that DIP1000 is only available if a function is marked @safe?
>
> It seems to me that both @live and @safe should be available as compiler flags to turn them on - and not have to rely on annotations. Is this possible? Certainly in Laser-D I would like these to be ON by default and annotation should be to suppress rather than enable.

a) Current measures are indeed not as thorough as rust's.

b) No. If you want to implement the switch you can but it would not only break a lot of code (live is not ready for prime time for example) but immediately fragment the language.

The memory safety features are not properly documented but the specification is not without mention of them, but in general the language is woefully underspecified.
3 days ago
On 22.11.20 03:28, Dibyendu Majumdar wrote:
> Hi
> 
> I don't quite know Rust so it is bit hard to compare this feature with Rust. Ideally someone who knows both languages in depth should compare and figure out if @live is comparable to Rust ownership ideas.
> 
> I have following questions / suggestions:
> 
> a) I understand on its own @live is only part of what Rust does? Rust has lifetime annotations and I believe it can track memory allocation across a graph of objects and ensure there is no leak etc. Is my understanding correct that @live only deals with pointers and to compare this to Rust, one has to also include DIP1000?
> ...

@live is not particularly comparable to what Rust does. Rust ensures safety modularly, while @live does not. Memory ownership is not built into Rust at the language level, only borrowing is. Forcing ownership semantics on built-in pointers does not make a lot of sense, as they have no associated allocator so pointer deallocation remains unsafe.

> My first suggestion is that @live and DIP1000 features should be documented together. I heard in the discussions that DIP1000 is actually not yet documented?
> 
> b) Is it also the case that DIP1000 is only available if a function is marked @safe?
> ...

`@live` attempts to respect `return` annotations on scoped pointers even in @system code.

E.g., this works as expected:
---
import core.stdc.stdlib;
int* foo(return scope int* x)@live{
   return x;
}
@live void main(){
   int* p=cast(int*)malloc(int.sizeof);
   scope int* q=foo(p);
   free(p);
}
---

But I think there isn't really a coherent lifetime design, e.g., this is a memory leak:
---
import core.stdc.stdlib;
struct S{int* a,b;}
void main()@live{
    auto q=S(cast(int*)malloc(int.sizeof),cast(int*)malloc(int.sizeof));
    free(q.a);
}
---

And of course, as soon as you use the standard library all bets are off, e.g. this is a double free in elegant range notation:

---
import std.range, core.stdc.stdlib;
void main()@live{
    repeat(cast(int*)malloc(int.sizeof),2).each!free;
}
---

It also works with a standard `foreach` loop:

void main()@live{
    foreach(p;repeat(cast(int*)malloc(int.sizeof),2))
        free(p);
}

> It seems to me that both @live and @safe should be available as compiler flags to turn them on - and not have to rely on annotations. Is this possible? Certainly in Laser-D I would like these to be ON by default and annotation should be to suppress rather than enable.

`@live @safe` makes no sense. Per the documentation, `@safe` already ensures memory safety on its own and `@live` is just a bunch of checks and dataflow analysis without an underlying modular safety story. Indeed, putting `@safe` on the examples above will correctly reject them.

Also, there is no keyword to disable `@live`.
3 days ago
On 11/21/2020 6:28 PM, Dibyendu Majumdar wrote:
> a) I understand on its own @live is only part of what Rust does? Rust has lifetime annotations and I believe it can track memory allocation across a graph of objects and ensure there is no leak etc.

Rust has an additional capability of specifying which function argument lifetime gets attached to the return type, whereas @live just takes the tightest lifetime of the supplied arguments. This was discussed a while back, and this extra (and optional) specification does not appear to add much value. We can always add it later if it turns out to be critical.


> Is my understanding correct that @live only deals with pointers and to compare this to Rust, one has to also include DIP1000?

DIP1000 is intended to be a core feature, not an optional one. It's been around long enough and is successful enough to become the default. @live assumes DIP1000.


> My first suggestion is that @live and DIP1000 features should be documented together. I heard in the discussions that DIP1000 is actually not yet documented?

DIP1000 will be for all D code, not just @live.


> b) Is it also the case that DIP1000 is only available if a function is marked @safe?

It's an enhancement for @safe, yes.


> It seems to me that both @live and @safe should be available as compiler flags to turn them on - and not have to rely on annotations. Is this possible? 
> Certainly in Laser-D I would like these to be ON by default and annotation
> should be to suppress rather than enable.

My DIP to make @safe the default failed.

Turning @live on by default would be brutal :-)
3 days ago
On 11/21/2020 7:37 PM, Timon Gehr wrote:
> `@live @safe` makes no sense. Per the documentation, `@safe` already ensures memory safety on its own

Only if you're using the GC to manage memory. @safe does not deal with lining up mallocs and frees. It's also not going to manage the memory of containers (your first example) - the user will be expected to craft the container to take care of that, for example by boxing the owning pointer.


> and `@live` is just a bunch of checks and dataflow analysis without an underlying modular safety story. Indeed, putting `@safe` on the examples above will correctly reject them.

@live is not redundant with nor a replacement for @safe. It enables a specific set of checks that are independent from @system/@trusted/@safe, though it is best used with @safe.


> Also, there is no keyword to disable `@live`.

That's right. If that's the big problem with @live, I'd consider @live a resounding success :-/

Please understand that the current @live implementation is a prototype. I expect we'll be learning a lot about how to use it properly. Rust went through considerable evolution, too. I don't expect @live to wind up in the same place as Rust any more than D's functional programming capabilities turn it into Haskell.
3 days ago
On Sunday, 22 November 2020 at 07:22:22 UTC, Walter Bright wrote:
> On 11/21/2020 6:28 PM, Dibyendu Majumdar wrote:
>> a) I understand on its own @live is only part of what Rust does? Rust has lifetime annotations and I believe it can track memory allocation across a graph of objects and ensure there is no leak etc.
>
> Rust has an additional capability of specifying which function argument lifetime gets attached to the return type, whereas @live just takes the tightest lifetime of the supplied arguments. This was discussed a while back, and this extra (and optional) specification does not appear to add much value. We can always add it later if it turns out to be critical.
>

Hi Walter, are you aware of the explicit lifetime annotation facility in Rust?

https://doc.rust-lang.org/rust-by-example/scope/lifetime/explicit.html

This seems critical to allow correct lifetime calculations in a graph of objects.

I read in DIP1000 that there is an automatic lifetime calculation when 'scope' storage class is used? However does that work with nested object graphs?

Rust had to have explicit annotations I believe as automated calculations are not sufficient.
3 days ago
On Sunday, 22 November 2020 at 07:22:22 UTC, Walter Bright wrote:

>> b) Is it also the case that DIP1000 is only available if a function is marked @safe?
>
> It's an enhancement for @safe, yes.
>
>
>> It seems to me that both @live and @safe should be available as compiler flags to turn them on - and not have to rely on annotations. Is this possible?
> > Certainly in Laser-D I would like these to be ON by default
> and annotation
> > should be to suppress rather than enable.
>
> My DIP to make @safe the default failed.
>
> Turning @live on by default would be brutal :-)

I read DIP1028. However, my suggestion is somewhat different - it is to allow a compiler flag - say -fdefault-safe - such that any code that is not annotated explicitly gets a default of @safe. Thus anyone using this flag would not need to explicitly annotate with @safe. I also suggest not changing the meaning of anything other than just defaulting as above.

@live is more complicated I suppose as it can't deal with GC pointers?


3 days ago
On Sunday, 22 November 2020 at 11:14:00 UTC, Dibyendu Majumdar wrote:

> @live is more complicated I suppose as it can't deal with GC pointers?

Another point is if @live is only usable on functions that take non-GC pointers then someone who uses this is probably already having to analyse manually to decide whether to apply @live, which kind of makes it redundant?
3 days ago
On 22.11.20 08:22, Walter Bright wrote:
> DIP1000 is intended to be a core feature, not an optional one. It's been around long enough and is successful enough to become the default. @live assumes DIP1000.

So far, DIP1000 is not a success. It's buggy, poorly documented, hard to understand. Phobos only compiles with -preview=dip1000 by relying on accepts-invalid bugs.
3 days ago
On Sunday, 22 November 2020 at 11:25:11 UTC, Dibyendu Majumdar wrote:
> On Sunday, 22 November 2020 at 11:14:00 UTC, Dibyendu Majumdar wrote:
>
>> @live is more complicated I suppose as it can't deal with GC pointers?
>
> Another point is if @live is only usable on functions that take non-GC pointers then someone who uses this is probably already having to analyse manually to decide whether to apply @live, which kind of makes it redundant?

Yes, this kind of pointer analysis really need to be done for the whole program. And there is no need to do it for every compile, so... Make dmd generate the verification source and use an external tool for verification... @live is not heading where it should be.
« First   ‹ Prev
1 2 3