For example, let a: []int = alloc([1,2,3]); is compiled with a
*[3]int -> []int implicit cast.
I guess it makes sense that this cast is not allowed, but then harec needs to handle special cases around alloc with dedicated code, not by abusing the cast mechanism. The gen code that enables this should also be (re)moved.
The spec allows assignment from array pointers to slices though? I don't see what the issue is here
The issue is that the spec doesn't allow casts from array pointers to slices. I overlooked the fact that it allows assignments, so I guess this is also a spec issue? I'm not sure.
The point is that there should be rules for what
lower_implicit_castcan and cannot do (checked with a bunch of asserts probably), because right now anything can be passed in and it's up to gen to decide whether it is to be compiled or not, and gen has support for some stuff that shouldn't be there according to the spec.
The issue is that the spec doesn't allow casts from array pointers to slices.
Ah, nice catch. Yup, that's a spec issue; this cast should be allowed (for bounded arrays).
The point is that there should be rules for what lower_implicit_cast can and cannot do (checked with a bunch of asserts probably), because right now anything can be passed in and it's up to gen to decide whether it is to be compiled or not, and gen has support for some stuff that shouldn't be there according to the spec.
The spec doesn't have a concept of "implicit casts"; it only has castability and assignability. There's been some talk about making a distinction between assignment and implicit casts, but as Hare currently stands, implicit casts are just an implementation detail.
The current intent is that assignability rules are a subset of castability rules, with the exception that
nevercan be assigned to any type, but not casted.So the assignment from alloc to []int doesn't depend on castability rules at all. I don't think alloc needs any special casing here (within either harec or the spec), sans issues with type hints (which is a separate thing). I also don't think the spec needs any updating, besides adding the missing array pointer -> slice castability rule. Making harec's code nicer and more maintainable is definitely good, but I don't think this is a correctness issue; I'm not aware of any instances where harec's rules for assignability/castability don't match those of the spec. Do you know of any?
The spec doesn't have a concept of "implicit casts"; it only has castability and assignability. There's been some talk about making a distinction between assignment and implicit casts, but as Hare currently stands, implicit casts are just an implementation detail.
Yeah I know implicit casts are just an internal harec thing. I don't think they need to be a distinct concept, in fact, I think they're linked more closely than it looks like if one doesn't read the code carefully enough. Out of 24 uses of
type_is_assignableincheck.c, 20 of them are immediately followed by a call tolower_implicit_cast. Out of all the uses oflower_implicit_cast, most of the ones that are not preceded by an assignability check are either subtly wrong, unneeded, or the assignability is implicitly established in the code by other means.Again, I realize this is all just implementation details and has no factual relevance to the abstract language as defined by the spec, but looking at how implementation has developed organically, can be a very good heuristic.
The current intent is that assignability rules are a subset of castability rules, with the exception that never can be assigned to any type, but not casted.
+1
So the assignment from alloc to []int doesn't depend on castability rules at all. I don't think alloc needs any special casing here (within either harec or the spec), sans issues with type hints (which is a separate thing). I also don't think the spec needs any updating, besides adding the missing array pointer -> slice castability rule. Making harec's code nicer and more maintainable is definitely good, but I don't think this is a correctness issue;
The remark about alloc special casing was made based on a couple of incorrect assumptions, all originating from the fact that I was not aware
*[3]int -> []intis a valid assignment. I agree now that no special casing is needed. This ticket was only meant to track issues with internal handling of implicit casts, I never meant to imply there's anything wrong with the spec (aside from that missing castability rule).I'm not aware of any instances where harec's rules for assignability/castability don't match those of the spec. Do you know of any?
Assigning to
voidis not allowed from an arbitrary type in harec, but is supposed to be allowed from any type according to the spec. Same fordone. I can't remember anything else right now, but I'm sure there are things I've seen relatively recently that don't behave well.