On Monday, 30 March 2020 at 12:58:33 UTC, Dukc wrote:
> On Saturday, 28 March 2020 at 20:24:02 UTC, Walter Bright wrote:
>> [...]
>
> I have recently added a lot of unittests to my code. That confirmed me that as we all know, it is a mandatory to do if I even a remotely bug-free program is desired :). And that's in a program that already had no global state and used ranges, `final switch`es and `assert`s fairly much.
>
> [...]

It's easier to use asan with ldc. I did write an allocator to do this before asan was available though: https://github.com/atilaneves/test_allocator

On Saturday, 28 March 2020 at 20:24:02 UTC, Walter Bright wrote:
> https://news.ycombinator.com/item?id=22711391
>
> Fitting in with the push for @safe as the default, and the @live Ownership/Borrowing system for D.
>
> We can either get on the bus or get run over by the bus.

Why is this news?
Clang has had this for a decade, and it certainly wasn't the first. If there is a bus, it's left the station a very long time ago.

Isn't it more interesting to find a comprehensive resource management solution, instead of working on a solution only for the special case of memory [*]. A double file close is also bad, for example.
Maybe RAII and move semantics isn't it, but at least it doesn't single out one type of resource.

-Johan

[*] Let alone the even more special case of functions with the exact symbol names "malloc" and "free" in this case...

On 3/30/2020 12:25 PM, Johan wrote:
> Clang has had this for a decade

Do you mean RAII? RAII is only a partial solution. For example, it is quite easy for an RAII object to leak a reference to its internals, and then the RAII object gets deleted, but the reference is still there.

On Monday, 30 March 2020 at 19:25:53 UTC, Johan wrote:
> On Saturday, 28 March 2020 at 20:24:02 UTC, Walter Bright wrote:
>> https://news.ycombinator.com/item?id=22711391
>>
>> Fitting in with the push for @safe as the default, and the @live Ownership/Borrowing system for D.
>>
>> We can either get on the bus or get run over by the bus.
> Isn't it more interesting to find a comprehensive resource management solution, instead of working on a solution only for the special case of memory [*]. A double file close is also bad, for example.
> Maybe RAII and move semantics isn't it, but at least it doesn't single out one type of resource.

I have to agree with you, most of the time I don't care about memory, but rather whatever I am modelling within that memory. Yes, that 24 might look right a regular int, but to me it holds significance beyond the fact that it is a mere int.

For my web library spasm I am dealing with JS objects that I have to release at the right time. Things get hairy with delegates, callback and long lived references.

At first I tried reference counting, but found out there was significant bloat (I like to keep my web binaries small), eventually I settled for non-copyable objects so I get unique references, and release them on the JS side when the last and only reference goes out of scope.

Of course now I run into other issues. 'scope ref' helps a bit, but I find that I have to write `move` a lot. The parts where I am struggling a bit are where I get a handle to an JS object that is conceptually a sumtype, an optional or a base object and need to unwrap or up cast things. I have solved them, but with some rather gnarly @system code.

Remember, I want unique references (and borrow) to plain ints here. I know it might look to the compiler as a regular int it can simply copy (and it is), but to me it looks like a JS mouseevent object that needs clean up after the last reference is gone.

On Tuesday, 31 March 2020 at 07:26:38 UTC, Sebastiaan Koppe wrote:
> At first I tried reference counting, but found out there was significant bloat (I like to keep my web binaries small), eventually I settled for non-copyable objects so I get unique references, and release them on the JS side when the last and only reference goes out of scope.

How do you do this? Do you do ref counting on the JS side?

I see that there is a proposal for weak references for javascript:
https://v8.dev/features/weak-references

I guess that could be useful.

On Tuesday, 31 March 2020 at 11:38:40 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 31 March 2020 at 07:26:38 UTC, Sebastiaan Koppe wrote:
>> At first I tried reference counting, but found out there was significant bloat (I like to keep my web binaries small), eventually I settled for non-copyable objects so I get unique references, and release them on the JS side when the last and only reference goes out of scope.
>
> How do you do this? Do you do ref counting on the JS side?

No, I keep all the JS objects in a JS array so the GC won't free them. When the time comes I call a release function from D, which removes the object from the array.

In the off case the D code takes the hold of the same JS object twice (e.g. twice the same querySelector or similar), there would be 2 entries in the JS array for the same object, each having their own unique reference.

JS engines do objects in arrays pretty well. It works nicely combined with the unique reference semantics I have on the D side. And if you really need to you can wrap it in a refcount and get the best of both worlds.

> I see that there is a proposal for weak references for javascript:
> https://v8.dev/features/weak-references
>
> I guess that could be useful.

That is pure JS though. There is a webassembly proposal to introduce anyref, whereby you can move js objects into wasm, and the js engine will track them. It might take a while before that is available.

On Monday, 30 March 2020 at 13:20:08 UTC, Atila Neves wrote:
>
> It's easier to use asan with ldc. I did write an allocator to do this before asan was available though: https://github.com/atilaneves/test_allocator

Yeah, something like those is what I meant. Thanks - I have to remember those when next having problems with `malloc`s.

Lowering the bar to use a tool like these is IMO more effective than pushing Rust-like static analysis. Basically, to cut down memory problems a sanitizer should be as easy to use as the built-in `unittest`s. Sure static checks can be useful too, but to be worth it they need to be easier to use than the sanitizer, and in any case static checks can't completely replace sanitizers.

On Tuesday, 31 March 2020 at 23:08:01 UTC, Dukc wrote:

> Basically, to cut down memory problems a sanitizer should be as easy to use as the built-in `unittest`s.

It is:

dflags: "-fsanitize=address" platform="ldc"


If you're not using dub, then:

ldc2 -fsanitize=address --unittest $REST_OF_ARGS

On Tuesday, 31 March 2020 at 01:26:50 UTC, Walter Bright wrote:
> On 3/30/2020 12:25 PM, Johan wrote:
>> Clang has had this for a decade
>
> Do you mean RAII? RAII is only a partial solution. For example, it is quite easy for an RAII object to leak a reference to its internals, and then the RAII object gets deleted, but the reference is still there.

I meant static analysis.

On Wednesday, 1 April 2020 at 14:30:20 UTC, Atila Neves wrote:
> On Tuesday, 31 March 2020 at 23:08:01 UTC, Dukc wrote:
>> Basically, to cut down memory problems a sanitizer should be as easy to use as the built-in `unittest`s.
>
> It is:
>
> dflags: "-fsanitize=address" platform="ldc"
>
>
> If you're not using dub, then:
>
> ldc2 -fsanitize=address --unittest $REST_OF_ARGS

Great!