Bonkers Transexual Pseudo-Hacker.
Comment by ~autumnull on ~sircmpwn/hare-wayland
whoops, my bad this is a duplicate of #4
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
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.
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
, andmatch
, andif
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
andyield
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
andmatch
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 preferswitch (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 thatyield
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
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 likeenum
except:
- enumeration values would count as
1<<N
rather thanN
- 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.
Comment by ~autumnull on ~sircmpwn/hare
assuming this means "defines" instead of "build tags".
Comment by ~autumnull on ~sircmpwn/hare
this issue would likely be addressed by a
nomem
builtin: https://lists.sr.ht/~sircmpwn/hare-dev/%3C09e046d7-1e38-1362-4870-1448781f956c%40posteo.net%3E
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.
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::]].
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);