todo.sr.ht

#963 link back to the relevant section from the syntax summary 9 hours ago

Ticket created by ~ecs on ~sircmpwn/hare

it'd be nice if eg. the entry for allocation-expression in the language syntax summary had a link to the allocations section in the spec proper

#960 issues with array literal type inference a month ago

on ~sircmpwn/hare

We could afford to be a bit more permissive here (especially with null), but I don't think it's a big deal to be order dependent. It simplifies the compiler, and allows you to figure out the array's member type just by looking at the first member. We already have a bunch of type deduction systems; it would suck to add yet another one, outside of some simple stuff like with nulls and nullable pointers.

the order-dependence here has always smelled a bit to me, but tbh it's not the worst thing - i'd be ok with shipping hare 1.0 with those array semantics, and i'm not sure it's worth adding substantially more complexity in order to improve this

If it's not a big deal to be order dependent here, why do we bother with type reduction at all? Reordering switch/match or even if cases is actually much more feasible than reordering array elements.

I don't mean that entirely seriously, but I do think the reasoning for avoiding order dependence applies equally here and for branching expresion result calculation. The only difference is that array literals are much less common than branching, but that should not be an excuse for intentionally giving them inferior semantics.

I totally agree this isn't worth much additional complexity, but at the same time, not being able to accomodate this use case indicates that perhaps our other deduction systems need adjustment, which by itself does not imply increase in complexity.
Type reduction has some weird semantics that would make it unsuitable for use here without modification (see #945, and my comment on it):
let x: (*int | nullable *int) = &0;
let a = [x, x];
a's type should be [2](*int | nullable *int), but with type reduction it would be [2]nullable *int.
Yeah I was speaking of some abstract future version of type reduction that is more reasonable than what we currently have.

Honestly, #945 and some other problems with type reduction make me think it's way too elaborate and we should make it simpler and leave complex cases for the user to resolve manually. Perhaps that would make it directly usable here as well.
Related to #952, we should also decide whether we want to allow never expressions: let a = [1, abort()]; (or with flipped order).

Some comments on some of the cases you gave:
let a = [[], [1]: []u8]; // [2][]u8
With the slice assignment RFC, this would become let a = [null, &[1]: []u8];, which makes it easier to make that work.
let a = [[1], [1u8]]; // [2][1]u8
I feel like I remember this intentionally not working (in that order)? Because it would complicate the compiler or something? ~ecs would know more about that, since it involves flexible types.
fyi [1]iconst et al is exactly what i opted to avoid - sticking iconst inside aggregate types, in ways that affect their size, means that lowering iconsts requires updating the aggregates' sizes, which sucks

Okay yeah this one was not very well thought out.

On a tangent, Harec's reliance on fixed sizes during check is quite unreasonable at times. I have a patchset prepared (and some more in preparation) that improves some of that. I'm not really advertising for flexible literals in aggregate types here, just pointing out this particular technical obstacle is (mostly) going away at some point.
let a = [[1u8], [1i]]; // should not be [2]([1]u8 | [1]int)
What about [[1u8], [1i], [1i: (u8 | int)]]?
Probably not? It essentially requires the compiler to "see through" the array literal. And that very quickly leads to intractable stuff. We actually do already have something kind of similar in tuple literal type inference, and it feels very out of place.

[[1u8], [1i], [1i]: ([1]u8 | [1]int] on the other hand should be fine.
let a = [[1,2,3], [1,2]]; // should not be [2]([2]int | [3]int)
Speaking of the slice assignability RFC: should [&[1, 2, 3], &[1, 2]] be allowed (with type [2][]int)? How about [[1, 2, 3][..], &[1, 2]]? I don't think those should be allowed, but if the other cases you gave are allowed, then allowing these would make some sense.
I haven't thought about slice assignability RFC hard enough yet to give an informed answer. My guess would be no for [&[1, 2, 3], &[1, 2]] since there is no indication from the user that they want a slice. [[1, 2, 3][..], &[1, 2]] does have an indication. So, maybe that should be fine?
Ooh, what about expandable arrays?
let a = [[0...], [1, 2, 3]]; // [2][3]int ?
That would be desirable, I think. And hopefully not too hard once we get expandable arrays in order.

#960 issues with array literal type inference a month ago

Comment by ~ecs on ~sircmpwn/hare

fyi [1]iconst et al is exactly what i opted to avoid - sticking iconst inside aggregate types, in ways that affect their size, means that lowering iconsts requires updating the aggregates' sizes, which sucks

the order-dependence here has always smelled a bit to me, but tbh it's not the worst thing - i'd be ok with shipping hare 1.0 with those array semantics, and i'm not sure it's worth adding substantially more complexity in order to improve this

#960 issues with array literal type inference a month ago

on ~sircmpwn/hare

We could afford to be a bit more permissive here (especially with null), but I don't think it's a big deal to be order dependent. It simplifies the compiler, and allows you to figure out the array's member type just by looking at the first member. We already have a bunch of type deduction systems; it would suck to add yet another one, outside of some simple stuff like with nulls and nullable pointers.

Type reduction has some weird semantics that would make it unsuitable for use here without modification (see #945, and my comment on it):
let x: (*int | nullable *int) = &0;
let a = [x, x];
a's type should be [2](*int | nullable *int), but with type reduction it would be [2]nullable *int.

Related to #952, we should also decide whether we want to allow never expressions: let a = [1, abort()]; (or with flipped order).

Some comments on some of the cases you gave:
let a = [[], [1]: []u8]; // [2][]u8
With the slice assignment RFC, this would become let a = [null, &[1]: []u8];, which makes it easier to make that work.
let a = [[1], [1u8]]; // [2][1]u8
I feel like I remember this intentionally not working (in that order)? Because it would complicate the compiler or something? ~ecs would know more about that, since it involves flexible types.
let a = [[1u8], [1i]]; // should not be [2]([1]u8 | [1]int)
What about [[1u8], [1i], [1i: (u8 | int)]]?
let a = [[1,2,3], [1,2]]; // should not be [2]([2]int | [3]int)
Speaking of the slice assignability RFC: should [&[1, 2, 3], &[1, 2]] be allowed (with type [2][]int)? How about [[1, 2, 3][..], &[1, 2]]? I don't think those should be allowed, but if the other cases you gave are allowed, then allowing these would make some sense.