On Sun Mar 2, 2025 at 11:06 PM EST, Luna wrote:
> Hello all,
>
> I encountered some strange behavior where a deferred statement that
> modifies a variable with a comlepx type like a struct or tuple that is
> then returned seems to be executed before the return value is evaluated:
>
>   fn return_data() (u8, u8) = {
>     let return_value: (u8, u8) = (5, 0);
>     defer return_value.0 = 2;
>     return return_value;
>   };
>
>   export fn main() void =

On Fri Jan 17, 2025 at 11:10 AM EST, Lorenz (xha) wrote:
> On Fri, Jan 17, 2025 at 03:55:29AM +0100, Bor Grošelj Simić wrote:
> > Arrays can't be used in binary expressions, so it makes no sense to do
>
> sorry, but what is a binary expression?

Same thing as what harec calls a "binarithm" expression. That is, an
expression with an infix operator and two operands (as opposed to a
unary expression like *x).

On Wed Jan 15, 2025 at 10:06 AM EST, Armin Preiml wrote:
>  // Compiles a template string. The return value must be freed with [[finish]]
>  // after use.
> -export fn compile(input: str) (template | invalid) = {
> +export fn compile(input: str) (template | invalid | nomem) = {
>  	let buf = memio::dynamic();
>  	defer io::close(&buf)!;
>  
>  	let instrs: []instruction = [];
> +	let ok = false;
> +	if (!ok) finish(&instrs);
> +
>  	const iter = strings::iter(input);
>  	for (let rn => strings::next(&iter)) {

On Fri Jan 10, 2025 at 4:37 AM EST, Drew DeVault wrote:
> On Fri Jan 10, 2025 at 2:58 AM CET, Bor Grošelj Simić wrote:
> > I'm not sure this is worth implementing in harec right now though. The code
> > handling bindings is already a huge mess and I'd like to reduce that mess
> > first. Sebastian has patches (I'm not sure about their completion status) for
> > the disallow multiple bindings RFC. Those need to be upstreamed, then I want to
> > make a couple of changes that reduce code duplication across different kinds of
> > bindings and fix a bunch of bugs and inconsistencies, then we can do this, if
> > we want to.
>
> fwiw I'm still soft NACK to disallowing multiple bindings.

Last I remember when we talked about this on IRC, your stace on this was
NACK for local bindings, but ok for top-level declarations. My patches

> 	union {
> 		struct {
> 			tag: u32,
> 			val: int,
> 		} int_,
> 		struct {
> 			tag: u32,
> 			// 4 bytes of padding
> 			val: str,
> 		} str_,
> 	}

Uh, pretend the syntax of that is correct and not a weird mix of Hare
and C syntax lol

On Fri Jan 3, 2025 at 5:15 PM EST, Luna wrote:
> Hi!
>
> This cast does very strange things that I do not understand:
>
>   let evil = (("a": (int | str)): int);
>
> The variable "evil" now behaves very strangely.
>
>   // All equality tests seem to pass.
>   assert(evil == 2);
>   assert(evil == 99);
>
>   // This reads "evil" as a different number sometimes, even though it

Hm, I think the current behavior is correct (and the spec is wrong).
People expect the ... operator to act as a tagged union squishing
operator (and in the future it will likely be made exclusive to tagged
unions (if they don't squish implicitly)), and the current behavior
makes that work as expected. Changing it to only dealias one layer
silently breaks some code which used ... in a reasonable way, such as in
hare::parse::doc::. That makes the operator much less useful, and adds a
footgun which seems unnecessary if we'll eventually effectively revert
the behavior anyway.

The patch getting rid of doc::error may still be worthwhile though, as
part of a broader plan to update functions to return specific error
types rather than combining them all into a module's error type (as you
brought up on #hare-dev a few days ago).

On Tue Dec 17, 2024 at 6:18 AM EST, Bor Grošelj Simić wrote:
> > > Also, is this newly documented behavior the most sensible thing to do? I'd say
> > > positioning it on the first invalid byte makes more sense.
> >
> > The issue there is that you wouldn't be able to easily recover from an
> > invalid UTF-8 error, since it would repeatedly try to decode the same
> > invalid byte over and over again.
> >
> > Maybe utf8::invalid (and also utf8::more) should be []u8, and store the
> > data of the invalid codepoint which triggered the error?
>
> Dealing with and recovering from utf8 decoding errors (and decoding
> errors in general) is hard. For example you have to decide when to count
> errors as separate and when to collapse multiple unexpected bytes into

On Tue Dec 17, 2024 at 4:15 PM EST, Drew DeVault wrote:
> Another drive-by note, I mentioned this on IRC but to repeat it here:
> I'm interested in removing @offset and keeping @packed, as well as
> making it easier to define unnammed placeholder/padding fields in
> structs by allowing any number of fields named _ to be silently
> discarded.

Last I remember you were hard NACK to removing @offset, but FWIW I'm
strong +1 to removing @offset and allowing unnamed fields with _.

On Tue Dec 17, 2024 at 3:48 PM EST, Drew DeVault wrote:
> On Tue Dec 17, 2024 at 9:25 PM CET, Sebastian wrote:
> > So, I like the idea of this, but its utility is somewhat limited. As you
> > mentioned, we wouldn't be able to use this in the stdlib for the most
> > part, since we return stack allocated objects. So we wouldn't be able to
> > get rid of the convention of not documenting internal types with this
> > RFC alone.
>
> See my review regarding stack allocation, it would work fine. It
> wouldn't behave exactly like opaque but it would be quite possible to
> prevent users from field-accessing "opaque" types from external modules
> while still knowing their size and alignment for stack allocation.
>
> To be clear, how this would support stack allocations in practice is: