Re: C-like static array size inference - how?
On 6/7/22 9:17 PM, forkit wrote: On Wednesday, 8 June 2022 at 01:11:45 UTC, Mike Parker wrote: ...The author withdrew the DIP .. That's a shame. Seems like a useful language feature. I'd be using it already if it existed. I agree, it's a pain to dig out an import and the verbose name, vs. just putting in the `$`. Not to mention, I don't know if 2-dimensional or n-dimensional static arrays are easy to capture with a library call + literal. These are the kinds of things that make D pleasant. Like `V[K2][K1]` being more intuitive than `HashMap!(K1, HashMap!(K2, V))`. I'd have gone for: int[..] arr = [1,2,3]; I like `$`. It's got a well-defined meaning, and already is somewhat magic. -Steve
Re: C-like static array size inference - how?
On Wednesday, 8 June 2022 at 01:11:45 UTC, Mike Parker wrote: ...The author withdrew the DIP .. That's a shame. Seems like a useful language feature. I'd be using it already if it existed. I'd have gone for: int[..] arr = [1,2,3];
Re: Comparing Exceptions and Errors
On 6/7/22 3:58 PM, frame wrote:
On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer wrote:
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
This is hard to encapsulate into a type, as dtors only hook
`scope(exit)` essentially.
-Steve
That's fine as the Throwable is still thrown but since `scope(failure)`
acts as like catch-block, people may use it as replacement if there is
something more to do.
I personally like the clean, short syntax when I don't care about the
actual exception or if I know the called function has already handled
the exception and just rethrows it:
```d
bool fun() {
scope(failure) {
// do something
return false;
}
badCode();
return true;
}
```
Wait, what?
I'm looking at the spec and it says:
A scope(exit) or scope(success) statement may not exit with a
throw, goto, break, continue, or return; nor may it be entered with a goto.
Which specifically does not include scope(failure).
I would never have expected that to be a "feature"...
I know this is bad as I'm capturing a possible error here - but this is
what an unexperienced coder would do, because it works. The better
approach would be to use `scope(exception)` (not typed, just as
keyword) that allows to act only on Exceptions so one cannot break
Exception vs Error paradigma and this also clarifies that usage of
`scope(failure)` is potentially dangerous if you return from it.
Anyway, I just put that here - maybe you mention it in your blog.
Ali's linked bug report suggests that it's happening for Errors too,
which is going to cause major problems if something didn't get cleaned
up properly.
I will update the blog post. My recommendation is going to be, don't
circumvent the propagation of the throwable for now. Instead use a `try`
+ `catch(Exception)`. I think we need a compiler change to not allow
return if it's catching an Error.
There may be other "weird" cases that are not covered by the spec. Is it
legal to goto a label inside scope(failure)?
Thanks for the heads up!
-Steve
Re: C-like static array size inference - how?
On Wednesday, 8 June 2022 at 00:43:24 UTC, Ali Çehreli wrote: Do I remember correctly that there were syntax proposals that used $ or _? int[$] arr = [ 1, 2 ]; int[_] arr = [ 1, 2 ]; But I can't find past discussions about that. https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md Links to the discussion and feedback threads are in the review summary. The author withdrew the DIP, so anyone who would like to pick it up again is free to do so.
Re: C-like static array size inference - how?
On 6/7/22 16:38, arandomonlooker wrote: There is any chance size inference is going to be implemented into D as a feature? Do I remember correctly that there were syntax proposals that used $ or _? int[$] arr = [ 1, 2 ]; int[_] arr = [ 1, 2 ]; But I can't find past discussions about that. Ali
Re: C-like static array size inference - how?
On Tuesday, 7 June 2022 at 00:20:31 UTC, Ali Çehreli wrote: On 6/6/22 17:04, arandomonlooker wrote: > [...] syntax causes > [...] As you already know, the correct syntax is 'int[]' :) but it won't work because -betterC cannot support dynamic array. [...] There is any chance size inference is going to be implemented into D as a feature?
Re: Comparing Exceptions and Errors
On 6/7/22 12:58, frame wrote:
> ```d
> bool fun() {
> scope(failure) {
> // do something
> return false;
> }
>
> badCode();
> return true;
> }
> ```
>
> I know this is bad as I'm capturing a possible error here - but this is
> what an unexperienced coder would do, because it works.
WAT! I think that's a bug. Simply having a 'return' statement suppresses
rethrowing the exception? Too subtle! The following bug is related:
https://issues.dlang.org/show_bug.cgi?id=21443
And the spec does not mention 'return' in scope(failure) having such a
huge effect. Uncommenting the 'return' line below causes wildly
different program behavior:
import std.stdio;
void main() {
writeln("main is calling zar");
zar();
}
void zar() {
scope (failure) {
writeln("zar is failing");
}
writeln("zar is calling bar");
bar();
}
void bar() {
scope (failure) {
writeln("bar is failing");
// return;
}
writeln("bar is calling foo");
foo();
}
void foo() {
writeln("foo is throwing");
throw new Exception("Oops!");
}
BUG! :)
Ali
Re: Comparing Exceptions and Errors
On Tuesday, 7 June 2022 at 18:37:13 UTC, Steven Schveighoffer
wrote:
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
This is hard to encapsulate into a type, as dtors only hook
`scope(exit)` essentially.
-Steve
That's fine as the Throwable is still thrown but since
`scope(failure)` acts as like catch-block, people may use it as
replacement if there is something more to do.
I personally like the clean, short syntax when I don't care about
the actual exception or if I know the called function has already
handled the exception and just rethrows it:
```d
bool fun() {
scope(failure) {
// do something
return false;
}
badCode();
return true;
}
```
I know this is bad as I'm capturing a possible error here - but
this is what an unexperienced coder would do, because it works.
The better approach would be to use `scope(exception)` (not
typed, just as keyword) that allows to act only on Exceptions so
one cannot break Exception vs Error paradigma and this also
clarifies that usage of `scope(failure)` is potentially dangerous
if you return from it.
Anyway, I just put that here - maybe you mention it in your blog.
Re: Comparing Exceptions and Errors
On 6/7/22 12:28 PM, frame wrote:
On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer wrote:
During the last beerconf, I wrote a short blog post about how `Error`
and `Exception` are different, and why you should never continue after
catching `Error`s.
I know the thematics but I still wonder why we only have
`scope(failure)` then? Anywhere where you will use this shiny thing with
a return statement will also catch any error that have occurred.
`scope(exit)` doesn't allow return statements, thus the only properly
clean design would be an additional `scope(exception)` guard.
My very common use of `scope(failure)` for my DB code:
```d
conn.exec("START TRANSACTION");
scope(success) conn.exec("COMMIT");
scope(failure) conn.exec("ROLLBACK");
```
This is hard to encapsulate into a type, as dtors only hook
`scope(exit)` essentially.
-Steve
Re: Comparing Exceptions and Errors
On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer wrote: During the last beerconf, I wrote a short blog post about how `Error` and `Exception` are different, and why you should never continue after catching `Error`s. I know the thematics but I still wonder why we only have `scope(failure)` then? Anywhere where you will use this shiny thing with a return statement will also catch any error that have occurred. `scope(exit)` doesn't allow return statements, thus the only properly clean design would be an additional `scope(exception)` guard.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On Tuesday, 7 June 2022 at 13:56:23 UTC, Steven Schveighoffer wrote: So you are safe, it will see the pointer inside the array reference, and see that it doesn't point at GC memory, so nothing further will be done. Thanks for the detailed explanation, and everyone who has replied.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On 6/6/22 6:18 PM, mw wrote:
Hi,
Suppose I have this code:
```
class GCAllocated {
float[] data;
this() {
// non-gc-allocated field
this.data = cast(float[])(core.stdc.stdlib.malloc(nBytes)[0 ..
nBytes]);
}
}
void foo() {
auto obj = new GCAllocated(); // gc-allocated owning object
...
}
```
So when `obj` is cleanup by the GC, obj.data won't be freed by the GC:
because the `data` is non-gc-allocated (and it's allocated on the non-gc
heap), the GC scanner will just skip that field during a collection
scan. Is this understanding correct?
Others have given answers on this, but I just want to clarify -- the GC
does *not* use any type information to scan for pointers. The default GC
has one bit to tell it whether a block contains pointers or not (if
true, it will treat every word as if it were a pointer), and it does not
understand array references, just pointers. The precise GC has a bitmap
of which words in the block are pointers, and it also does not
understand array references.
So you are safe, it will see the pointer inside the array reference, and
see that it doesn't point at GC memory, so nothing further will be done.
-Steve
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On Tuesday, 7 June 2022 at 09:12:25 UTC, ag0aep6g wrote: On 07.06.22 11:00, max haughton wrote: On Tuesday, 7 June 2022 at 08:56:29 UTC, ag0aep6g wrote: [...] That wasn't mw's question. I also answered this in my original one IIRC. You didn't. Ok I must have assumed it was obvious it wouldn't free it.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On 07.06.22 11:00, max haughton wrote: On Tuesday, 7 June 2022 at 08:56:29 UTC, ag0aep6g wrote: [...] That wasn't mw's question. I also answered this in my original one IIRC. You didn't.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On Tuesday, 7 June 2022 at 08:56:29 UTC, ag0aep6g wrote: On 07.06.22 03:02, max haughton wrote: I'm talking about the data in the array. void[] might contain pointers, float[] does not so it won't be scanned. That wasn't mw's question. I also answered this in my original one IIRC. There's nothing too free because the GC didn't allocate it. Every allocator needs to either have a GC or a fast way to free memory which includes checking whether it owns memory in the first place. annoyingly you can't express this in the malloc/free pattern very well at all. One of the many gifts C has given the world.
Re: want to confirm: gc will not free a non-gc-allocated field of a gc-allocated object?
On 07.06.22 03:02, max haughton wrote: I'm talking about the data in the array. void[] might contain pointers, float[] does not so it won't be scanned. That wasn't mw's question.
Re: C-like static array size inference - how?
On Tuesday, 7 June 2022 at 00:20:31 UTC, Ali Çehreli wrote: > it's complaining about TypeInfo being absent. What an unfortunate error message! Trying writeln() causes equally weird error messages. Walter just improved it! https://github.com/dlang/dmd/pull/14181 Perhaps try a [nightly build](https://github.com/dlang/dmd/releases/tag/nightly)
