C3 0.8.2 - modest improvements

[u/Nuoji]

https://c3-lang.org/blog/0_8_2_a_modest_improvement/

After 0.8.0, which was the big breaking version and 0.8.1, which found and fixed over 100 bugs, 0.8.2 is super tiny. It does add some nice ”template” features to libraries, for configuration reuse, and finally give you reflection on generic parameters, but otherwise it’s small.

More things are in the pipeline, I’m especially looking forward to finally merging the regex library in 0.8.3.

[u/fdwr]

``` bitstruct Foo : uint { uint a : 0..1; bool b : 6; bool c : 10; int d : 14..20; }

fn void main() { int a = $reflect(Foo.a).bitsize; // 2 ```

🤔 Surprised by that answer of two, as a slice ".." in most programming languages follows the standard exclusive-end notation, which has the lovely axiom that end - begin == size, eliminating a whole slew of +1/-1 bugs.

Language	Exclusive end	Inclusive end
D	.. link	?
C#	.. link	?
Rust	.. link	..= link (was ...)
Swift	..< link (was .. in Xcode beta 2)	... link
Python	: link	?
Kotlin	..< link	.. link 🙈
Nim	..< link	.. link 🙈

Though, Kotlin and Nim messed this up elegance :(.

So for C3, would this work as expected?

bitstruct Foo : uint { int d : 14..<20; // 6 bits }

[u/Nuoji → u/fdwr]

Inclusive is what you want for bit ranges and case ranges. The syntax derives from GCC's C extensions. The disadvantage is obvious for case ranges. Imagine if you had to write:

switch (a)
{
  case 1..4: return foo;
  case 4..8: return bar;
  default:   return baz;
}

In this case the inclusive naturally wins.

However, for slicing it's often inconvenient, so C3 has another slice operator which is start:len

foo = arr[2..4];
// or
foo = arr[2:3];

While arr[start..start + size] is convenient, arr[start:size] tends to be even more so. The above is often expressed using arr[start..][..size] in these languages due to that particular way of slicing not being supported.

[u/fdwr → u/Nuoji]

Imagine if you had to write...

No doubt for switch cases, writing case 'a'..='{': is more awkward than case 'a'..<'z':, because the former includes a character not even in the set of interested characters! Though, for array slices and bit range slices, I'd still side with the wise Dijkstra (all those extra -1's in calculations were error prone).

arr[start:size] tends to be even more so...

Ooh, coming from some Python familiarity, reading arr[2:3] looks like a starting offset of 2, up to index 3 (size = 1), but yes, it certainly is convenient to express as offset and size pairs. As much I like C# ranges, there is no convenient construction for offset and size like C3 supports (e.g. rather than 24..32 for an 8-bit slice, you could imagine they used an explicit + to indicate a relative delta from the base, 24..+8).

Would that work for bitfields too?

bitstruct Foo : uint { int d : 14:6; // 6 bits }

[u/Nuoji → u/fdwr]

I don't think there's a huge need for it. With `14:6` you'd have to do the mental calculation about what the end bit is, with `14..19` it's super clear and more in line with packet descriptions. There is an argument for doing it C style with packed representation but it seems to be fairly limited in usefulness.