~autumnull

Bonkers Transexual Pseudo-Hacker.


#17 scanner: generate destructors for interfaces that don't have them 8 months ago

Comment by ~autumnull on ~sircmpwn/hare-wayland

whoops, my bad this is a duplicate of #4

#17 scanner: generate destructors for interfaces that don't have them 8 months ago

Ticket created by ~autumnull on ~sircmpwn/hare-wayland

the scanner doesn't auto-generate destructors for interfaces that don't have them so the number of registered objects increases indefinitely.

C scanner section that does this: https://github.com/gitlab-freedesktop-mirrors/wayland/blob/56dfdb7614dd6485e228f662d7d2ae9ce8b68719/src/scanner.c#L1178-L1188

#822 Generalize labellable expressions 9 months ago

Comment by ~autumnull on ~sircmpwn/hare

I don't think they should be allowed on if expressions, for instance, since that would duplicate the behavior of compound expressions.

it's not quite duplicating the behavior of compound expressions, since there's an else branch, see:

if (...) :label1 {
	...
} else :label2 {
	...
};

requires an extra label compared to

:label if (...) {
	...
} else {
	...
};

the latter of these is far more legible imo, and makes it clearer what you're actually doing (yielding from the if/else statement)

keeping break/yield separate sounds fair enough, no strong opinions

i prefer the label as a prefix to the switch/match keyword, for consistency with for and compound expressions. i also think it's simpler to think about as yielding from the switch expression itself, similar to yielding from a chain of if/elses.

#822 Generalize labellable expressions 9 months ago

on ~sircmpwn/hare

It's been a little bit, and I figured I'd write down my current two cents here to hopefully maybe get a discussion going or something:

On the surface, generalizing labels to all expressions sounds like the right thing to do. But I don't think it actually is. As ~autumnull said, it really only makes sense in compound, if, for, switch, and match, and if can even be removed from that list since compound expressions take care of that. Outside of that list, though, labels are at best useless, and at worst semantic nightmares, as in the two examples in my first comment.

So, if they're not generalized to everything, then I want to be a bit picky for exactly where labels will be allowed. I don't think they should be allowed on if expressions, for instance, since that would duplicate the behavior of compound expressions.

Part of me doesn't mind the current semantics of breaking from a labelled for-loop body, but another part of me acknowledges that the semantics are very weird: break doesn't operate on compound expressions, it operates on loops. But yet selecting the loop to break from is done by using the label of a compound expression. So I think it's reasonable to allow for-loops to be labelled. Though it'd be nice to keep the rule that yield always operates on compound expressions, and break/continue always operate on loops, so e.g. you wouldn't be allowed to yield from a for-loop, and you wouldn't be allowed to break from a compound expression. I can see why people wouldn't like this, since it kinda feels like an arbitrary separation for what's pretty much the same operation, but break and yield already exist as separate things, and neither is going away, so I'd rather embrace their differences than make them identical when used with a label.

switch and match desperately need a way to be labelled. I have no strong opinions on the syntax we use here, but if I had to pick I'd say I prefer switch (0) :label { to :label switch (0) {, since the former makes it more clear that the label refers to the implicit compound expression of each case, rather than the switch expression itself (this distinction matters if we want to keep the rule that yield only operates on compound expressions). I could be persuaded otherwise though (and will very quickly concede if others disagree with me here), especially if we'd rather keep the syntax consistent across all expressions which can be labelled.

So, tl;dr:

// compound label
:label { yield :foo, 0; }; // must be yield, not break
// for label
:label for (true) { break :foo, 0; }; // must be break (or continue), not yield
// yielding to a labelled for-loop body is equivalent to continuing the loop itself
for (true) :label { yield :label; };
:label for (true) { continue :label; };
// switch label
switch (0) :label { case => yield :label, 0; };
// or
:label switch (0) { case => yield :label, 0; };
// ditto for match

#838 rethink spec for enums 1 year, 11 days ago

Comment by ~autumnull on ~sircmpwn/hare

i had an idea earlier today, which is that it might make sense to have a bitflag keyword, which would work like enum except:

  • enumeration values would count as 1<<N rather than N
  • exhaustivity checking would be different, probably being the same as the underlying type, and then enums could have proper exhaustivity checking where only each member must be covered.

#346 driver: provide build tags to dependencies 1 year, 21 days ago

Comment by ~autumnull on ~sircmpwn/hare

assuming this means "defines" instead of "build tags".

#410 harec: add -Fstrictoom flag 1 year, 21 days ago

Comment by ~autumnull on ~sircmpwn/hare

#659 driver: `hare build` can overwrite source files 1 year, 21 days ago

Comment by ~autumnull on ~sircmpwn/hare

imo best way to deal with this is to only overwrite existing files if they're regular files and are executable by the current user.

#832 haredoc: make docstring references to modules use trailing "::" 1 year, 22 days ago

Ticket created by ~autumnull on ~sircmpwn/hare

current:

// see the low-level functions available from [[rt]].

proposed:

// see the low-level functions available from [[rt::]].

#831 haredoc: show full identifiers 1 year, 22 days ago

Ticket created by ~autumnull on ~sircmpwn/hare

currently haredoc shows the identifiers as written in the code, but for submodules, this means that the identifier written will not produce a result when haredoc is queried with that value. e.g. haredoc strings::fromutf8 outputs:

fn fromutf8(in: []u8) (str | utf8::invalid);

and haredoc utf8::invalid produces no results. Instead, haredoc should show this:

fn fromutf8(in: []u8) (str | encoding::utf8::invalid);