RFC SUMMARY
hare builtin's should have some way of handling allocation failures.
most apps probably don't want to handle allocation failure but
rather crash. this proposal does not create any performance impact or
additional complications in these cases, except adding a trailing "!"
to builtins that might return nomem.
LANGUAGE IMPLICATIONS
nomem becomes a builtin type. it's error flag is always set. basicly
another void, unfortionately; as autumnull@ already explained in the
previous proposal, rt::nomem (or errors::nomem) doesn't make sense
because you would always have to import it. i think that its fine
to add a builtin for handling errors from builtins.
the return values are changed like so:
alloc() returns (*T | nomem)
static(opt) append() returns (void | nomem)
static(opt) insert() returns (void | nomem)
i think that the special case for alloc(), i.e., returning a type
based on it's argument and type hint, should be fine, because it's
very obvious to the user what is happening and not very hard to
implement.
the static expressions would have the same return values, but return
nomem when there is not enough capacity, not when the allocation
fails. because it's consistent with the non-static variants, the
programmer has to keep less in mind and i think this is also just
logical.
also, i don't think that we should change delete() here. it's not
very likely that a re-allocation fails and even then you can just
continue to use the old allocation, so it doesn't really matter
that much.
STANDARD LIBRARY IMPLICATIONS
errors::nomem is removed. it's used nowhere in the standard libary
except once in dirfdfs.
most standard libary functions should be able to handle allocation
failure simply by doing, for example, append()? and having "nomem"
in their "::error" type. users of these functions can then decide
how they want to handle allocation failure.
ECOSYSTEM IMPLICATIONS
this will probably break most hare libaries and apps ever written. it
should, however, be pretty easy to write a script that just appends an
"!" to all calls to alloc, insert and append.
EXAMPLE CODE
let y = match (alloc(1)) {
case let y: *int =>
yield y;
case nomem =>
[...]; // do Something on OOM
};
// could be optimized to "rt::malloc_or_abort()" or something pretty easily
let slice = alloc([1, 2, 3])!;
fn test() ([]int | nomem) = {
// could be optmized to `if [[unlikely]] (x == null) return nomem else yield x;`
let x = alloc([...])?;
return x;
};
RELATED RFCS
mostly stolen from autumnull@:
https://lists.sr.ht/~sircmpwn/hare-dev/%3C09e046d7-1e38-1362-4870-1448781f956c@posteo.net%3E
+1
On Sat Apr 6, 2024 at 8:08 AM EDT, Lorenz (xha) wrote:
> nomem becomes a builtin type. it's error flag is always set. basicly> another void, unfortionately
Yeah... I'm not a fan of this, but I've thought about allocation failure
handling quite a bit and I think this is the best approach.
> the return values are changed like so:>> alloc() returns (*T | nomem)> static(opt) append() returns (void | nomem)> static(opt) insert() returns (void | nomem)
+1, but see below
> the static expressions would have the same return values, but return> nomem when there is not enough capacity, not when the allocation> fails. because it's consistent with the non-static variants, the> programmer has to keep less in mind and i think this is also just> logical.
I hadn't really thought about this; I just assumed that the static
variants would always return void, but I guess this makes sense? I'm
indifferent about this.
> also, i don't think that we should change delete() here. it's not> very likely that a re-allocation fails and even then you can just> continue to use the old allocation, so it doesn't really matter> that much.
The spec requires that reallocation in delete() will never fail, so yeah
+1 to not making any changes here.
> this will probably break most hare libaries and apps ever written. it> should, however, be pretty easy to write a script that just appends an> "!" to all calls to alloc, insert and append.
Many functions which currently can't error would now be able to error,
so I think we should provide a more sophisticated program which can
correctly handle more of this (i.e. hareupdate (sorry for putting
lossless AST off for so long i promise i'll get to it at some point))
Also, we should encourage libraries to use error propagation here
instead of unconditionally aborting.
thanks for the feedback! unless there is some more feedback, my
plan is to implement this RFC this weekend.
On Tue, Apr 09, 2024 at 05:17:22PM -0400, Sebastian wrote:
> > this will probably break most hare libaries and apps ever written. it> > should, however, be pretty easy to write a script that just appends an> > "!" to all calls to alloc, insert and append.> > Many functions which currently can't error would now be able to error,> so I think we should provide a more sophisticated program which can> correctly handle more of this (i.e. hareupdate (sorry for putting> lossless AST off for so long i promise i'll get to it at some point))
i mean - if you can get hareupdate up and running that'd be nice, otherwise
i wouldn't want to create the next RFC that is blocked on the lossless AST.
i can convert the stdlib manually. the nice thing about this is that it
will actually not break silently.
> Also, we should encourage libraries to use error propagation here> instead of unconditionally aborting.
yes, i aggree. +1
> RFC SUMMARY>> hare builtin's should have some way of handling allocation failures.>> most apps probably don't want to handle allocation failure but> rather crash. this proposal does not create any performance impact or> additional complications in these cases, except adding a trailing "!"> to builtins that might return nomem.>> LANGUAGE IMPLICATIONS>> nomem becomes a builtin type. it's error flag is always set. basicly> another void, unfortionately;
We're having a bit of an explosion of these :(
It's not obvious what else to do though. At least for alloc it'd be great if we
found a way to actually use the fact that we can signal failure through NULL.
> as autumnull@ already explained in the> previous proposal, rt::nomem (or errors::nomem) doesn't make sense> because you would always have to import it. i think that its fine> to add a builtin for handling errors from builtins.>> the return values are changed like so:>> alloc() returns (*T | nomem)> static(opt) append() returns (void | nomem)> static(opt) insert() returns (void | nomem)>> i think that the special case for alloc(), i.e., returning a type> based on it's argument and type hint, should be fine, because it's> very obvious to the user what is happening and not very hard to> implement.>> the static expressions would have the same return values, but return> nomem when there is not enough capacity, not when the allocation> fails. because it's consistent with the non-static variants, the> programmer has to keep less in mind and i think this is also just> logical.
I'm a bit skeptical of this. It's tempting to let the user handle failed static
appends/inserts, but I'm not sure this is actually desired. Can you give a real
world example where this would be useful?
> also, i don't think that we should change delete() here. it's not> very likely that a re-allocation fails and even then you can just> continue to use the old allocation, so it doesn't really matter> that much.
If we want to delete to always succeed, we need to specify that (and fix
rt::unensure's behavior)
> STANDARD LIBRARY IMPLICATIONS>> errors::nomem is removed. it's used nowhere in the standard libary> except once in dirfdfs.>> most standard libary functions should be able to handle allocation> failure simply by doing, for example, append()? and having "nomem"> in their "::error" type. users of these functions can then decide> how they want to handle allocation failure.>> ECOSYSTEM IMPLICATIONS>> this will probably break most hare libaries and apps ever written. it> should, however, be pretty easy to write a script that just appends an> "!" to all calls to alloc, insert and append.
I think it's worth considering special versions - alloc?, alloc!, and the same
for insert and append. The fact that they're special makes it more clear that
there's more than just calls to regular functions and that the values it's
operating on are not really just usual tagged unions. I realize this makes
lexing harder, but I don't think that's very important here, what matters the
most is what's best for the users.
> thanks for the feedback! unless there is some more feedback, my> plan is to implement this RFC this weekend.
You're of course welcome to implement the rfc before it's approved or even
thoroughly discussed (it can help the discussion, even), but note that we're
moving kinda slowly around here and one week is generally not enough time for
all the relevant people to give feedback, so you may have to change substantial
things in the implementation afterwards.
*ping*
anyone? a simple "+1" would also be very much appriciated so i know
if i can continue implementing this.
On Sat, Apr 06, 2024 at 02:08:07PM +0200, Lorenz (xha) wrote:
> RFC SUMMARY> > hare builtin's should have some way of handling allocation failures.> > most apps probably don't want to handle allocation failure but> rather crash. this proposal does not create any performance impact or> additional complications in these cases, except adding a trailing "!"> to builtins that might return nomem.> > LANGUAGE IMPLICATIONS> > nomem becomes a builtin type. it's error flag is always set. basicly> another void, unfortionately; as autumnull@ already explained in the> previous proposal, rt::nomem (or errors::nomem) doesn't make sense> because you would always have to import it. i think that its fine> to add a builtin for handling errors from builtins.> > the return values are changed like so:> > alloc() returns (*T | nomem)> static(opt) append() returns (void | nomem)> static(opt) insert() returns (void | nomem)> > i think that the special case for alloc(), i.e., returning a type> based on it's argument and type hint, should be fine, because it's> very obvious to the user what is happening and not very hard to> implement.> > the static expressions would have the same return values, but return> nomem when there is not enough capacity, not when the allocation> fails. because it's consistent with the non-static variants, the> programmer has to keep less in mind and i think this is also just> logical.> > also, i don't think that we should change delete() here. it's not> very likely that a re-allocation fails and even then you can just> continue to use the old allocation, so it doesn't really matter> that much.> > STANDARD LIBRARY IMPLICATIONS> > errors::nomem is removed. it's used nowhere in the standard libary> except once in dirfdfs.> > most standard libary functions should be able to handle allocation> failure simply by doing, for example, append()? and having "nomem"> in their "::error" type. users of these functions can then decide> how they want to handle allocation failure.> > ECOSYSTEM IMPLICATIONS> > this will probably break most hare libaries and apps ever written. it> should, however, be pretty easy to write a script that just appends an> "!" to all calls to alloc, insert and append.> > EXAMPLE CODE> > let y = match (alloc(1)) {> case let y: *int =>> yield y;> case nomem =>> [...]; // do Something on OOM> };> > // could be optimized to "rt::malloc_or_abort()" or something pretty easily> let slice = alloc([1, 2, 3])!;> > fn test() ([]int | nomem) = {> // could be optmized to `if [[unlikely]] (x == null) return nomem else yield x;`> let x = alloc([...])?;> return x;> };> > RELATED RFCS> > mostly stolen from autumnull@:> https://lists.sr.ht/~sircmpwn/hare-dev/%3C09e046d7-1e38-1362-4870-1448781f956c@posteo.net%3E
On Mon Apr 22, 2024 at 11:43 PM EDT, Lorenz (xha) wrote:
> *ping*>> anyone? a simple "+1" would also be very much appriciated so i know> if i can continue implementing this.
+1. Even if we end up changing things, having an actual implementation
will be useful, and I can't imagine you'll need to throw it out and
start over or anything.
I still sorta dislike nomem being another "void" type, but I have no
better ideas. It wouldn't bother me nearly as much if we didn't have
`done`, but `done` actually is nearly identical to void, with some minor
differences here and there, and nomem will be pretty much the same
story.
+1 on the whole, i think you can go ahead and start implementing this.
similar disease as everyone else at adding another void type, but i
don't think there's anything better that can be done
On Sat Apr 6, 2024 at 12:08 PM UTC, Lorenz (xha) wrote:
> the static expressions would have the same return values, but return> nomem when there is not enough capacity, not when the allocation> fails. because it's consistent with the non-static variants, the> programmer has to keep less in mind and i think this is also just> logical.
+1, i like this, but i'd also be fine with having static expressions not
return nomem if that's the consensus we reach
> also, i don't think that we should change delete() here. it's not> very likely that a re-allocation fails and even then you can just> continue to use the old allocation, so it doesn't really matter> that much.
hrm, not sure i love this. i'd kinda prefer to have delete() match the
rest of the slice ops, and while re-allocation failure is less likely
(and recoverable if it does happen, at least in theory) it is still
possible. very soft -1, completely fine with implementing this as-is
On Thu Jul 25, 2024 at 1:59 AM EDT, Ember Sawady wrote:
> > also, i don't think that we should change delete() here. it's not> > very likely that a re-allocation fails and even then you can just> > continue to use the old allocation, so it doesn't really matter> > that much.>> hrm, not sure i love this. i'd kinda prefer to have delete() match the > rest of the slice ops, and while re-allocation failure is less likely > (and recoverable if it does happen, at least in theory) it is still > possible. very soft -1, completely fine with implementing this as-is
The current specification of delete requires that reallocation never
fails, which IMO is correct since it's easy to just use the old
allocation like Lorenz said (so it's possible more than just "in
theory"). I don't see any reason to allow delete to fail.
On Thu Jul 25, 2024 at 6:09 AM UTC, Sebastian wrote:
> On Thu Jul 25, 2024 at 1:59 AM EDT, Ember Sawady wrote:> > > also, i don't think that we should change delete() here. it's not> > > very likely that a re-allocation fails and even then you can just> > > continue to use the old allocation, so it doesn't really matter> > > that much.> >> > hrm, not sure i love this. i'd kinda prefer to have delete() match the > > rest of the slice ops, and while re-allocation failure is less likely > > (and recoverable if it does happen, at least in theory) it is still > > possible. very soft -1, completely fine with implementing this as-is>> The current specification of delete requires that reallocation never> fails, which IMO is correct since it's easy to just use the old> allocation like Lorenz said (so it's possible more than just "in> theory"). I don't see any reason to allow delete to fail.
(when i said "in theory", i mostly meant "rt::unensure doesn't do this
right now, unless someone changed it since last time i looked")
and yeah, thinking a bit harder, you're right. the behavior you want
when a delete() realloc fails is, with almost 100% certainty, to just
keep going with the old allocation. i retract my soft -1, though we
should fix rt::unensure
On Thu, Jul 25, 2024 at 05:59:15AM +0000, Ember Sawady wrote:
> +1 on the whole, i think you can go ahead and start implementing this.
still waiting for Drew, he wanted me to wait for his feedback.
Thank you for your patience in waiting for my feedback, Lorenz et al, I
know it was annoying while I was so busy IRL over the past few months.
Overall, I'm +1 to this proposal.
I think that this would be a good opportunity to develop at least a
prototype of hare update[^1]. I don't think we need to wait for the
lossless AST and the perfect approach that Seb has in mind before we can
ship something useful. Rather than parse in the AST, modify it in place,
and unparse it back out losslessly, this is a simple enough change that
it should be relatively easy to build simple primitives for parsing with
locations and making automated edits to the text file directly rather
than to the AST in memory. We can then have the tool which scans all
Hare sources in the cwd, identifies alloc usages, and prompts the user
to either:
1. Add an assertion !
2. Add a ? and update the return type
3. Open their editor to fix the code manually
I have some more thoughts on the UX and prototype-grade implementation
of this tool if anyone interested in working on it wants to sync up for
a chat. Perhaps Seb is up for working together with Lorenz to get this
done in the next release cycle to accompany nomem (maybe it'll be easier
to work on if you can envision a path forward which is not blocked on
lossless AST, Seb? I've never been sold on the lossless AST tbqh, we
should chat about this alternate design approach); otherwise I am not
firmly blocking this proposal on an automated upgrade procedure. Just
putting it out there if there's interest.
I am not convinced that static append/insert should return nomem instead
of void. It would be easier to eschew this approach if we added a
capacity built-in, but I don't want to tangle it up in this RFC. I'm
okay with moving forward with static append/insert returning nomem, but
expect me to raise the point for future discussion, and if we change our
mind at that point it would mean breaking user code twice; once now and
once then. If no one feels strongly about nomem, I put soft support
behind sticking with static append asserting on failure and punting the
question for a future discussion, in which case we only break it once if
we agree to do nomem at that time.
I agree that delete() should not return nomem, and should just not
release the original allocation if it cannot realloc. Matches C behavior
and expectations from Unix programmers.
Finally, I suspect that removing errors::nomem will be more complicated
than we anticipate, but we'll see what happens when we cross that bridge.
+1 to moving forward with an implementation -- nice work, Lorenz.
[^1]: Adding the space there was a typo, but come to think of it I
wonder if hare update might be a good candidate for adding to the build
driver... but only if we re-open the old wound of discussing hare(1)'s
scope, in which case I'll argue for the git-style /usr/libexec
approach ;) Ignore this entire footnote please
--
Drew DeVault
On Sun Jul 28, 2024 at 5:27 AM EDT, Drew DeVault wrote:
> I think that this would be a good opportunity to develop at least a> prototype of hare update[^1]. I don't think we need to wait for the> lossless AST and the perfect approach that Seb has in mind before we can> ship something useful. Rather than parse in the AST, modify it in place,> and unparse it back out losslessly, this is a simple enough change that> it should be relatively easy to build simple primitives for parsing with> locations and making automated edits to the text file directly rather> than to the AST in memory. We can then have the tool which scans all> Hare sources in the cwd, identifies alloc usages, and prompts the user> to either:>> 1. Add an assertion !> 2. Add a ? and update the return type> 3. Open their editor to fix the code manually>> I have some more thoughts on the UX and prototype-grade implementation> of this tool if anyone interested in working on it wants to sync up for> a chat. Perhaps Seb is up for working together with Lorenz to get this> done in the next release cycle to accompany nomem (maybe it'll be easier> to work on if you can envision a path forward which is not blocked on> lossless AST, Seb? I've never been sold on the lossless AST tbqh, we> should chat about this alternate design approach); otherwise I am not> firmly blocking this proposal on an automated upgrade procedure. Just> putting it out there if there's interest.
Something like this is definitely doable without lossless AST, and I
agree that we should have an automated migration procedure ready for the
next release. I still think lossless AST is the correct approach in
general (it's also useful for other things like formatters), but
specifically for adding error assertions to alloc/append/insert
expressions, the same effect can be achieved with a naive lexing and
editing in-place system.
I'm interested to hear your thoughts on the UX. My thought was that the
migration should be mostly automated: it should add an error assertion
to every alloc, without prompting the user. alloc (and append and
insert) are used *very* frequently, so being prompted for every single
one isn't much more convenient than just grepping for them all yourself
and fixing them all manually IMO. Adding an error assertion to all of
them causes the behavior to remain exactly the same as before the
migration in almost[^1] all cases. Of course, libraries should go
through and update themselves to use error propagation (or similar), but
this can be done gradually, and should be done with more thought (e.g.
does this function really need to allocate? + checking for memory leaks
which may occur when an allocation fails).
[^1]: The exception is when a nullable pointer type hint is used to
handle allocation failure with our current semantics. I don't think it's
necessary to handle this in hareupdate, since this is very rarely used,
and most of the time when it is used, it's unintentional and a bug.
Besides, properly handling this would require a hosted type checker.
> Finally, I suspect that removing errors::nomem will be more complicated> than we anticipate, but we'll see what happens when we cross that bridge.
Care to elaborate on this?
On Sun Jul 28, 2024 at 10:44 PM CEST, Sebastian wrote:
> Something like this is definitely doable without lossless AST, and I> agree that we should have an automated migration procedure ready for the> next release. I still think lossless AST is the correct approach in> general (it's also useful for other things like formatters), but> specifically for adding error assertions to alloc/append/insert> expressions, the same effect can be achieved with a naive lexing and> editing in-place system.
I think we can get pretty far with the in-place editing system, and I'd
be happy to see hare update decoupled from that.
> I'm interested to hear your thoughts on the UX. My thought was that the> migration should be mostly automated: it should add an error assertion> to every alloc, without prompting the user. alloc (and append and> insert) are used *very* frequently, so being prompted for every single> one isn't much more convenient than just grepping for them all yourself> and fixing them all manually IMO.
I think that it's easier to do it this way for sure, but this also
presents a great opportunity to identify places where users could take
advantage of the feature and improve their error handling.
The UX I have in mind is something like...
---
Hare 0.24.whatever changes the behavior of the alloc built-in to return
an error type (called nomem) when the allocation fails... blurb blurb
blurb prose explanation of the change blah blah blah
More information on this change:
https://harelang.org/updates/...
Choose from the following options:
[A]ssisted migration: review each case manually
Au[t]omatic migration: add an error assertion (!) to all cases
[S]kip: do nothing
Your choice [a/t/s, default 'a']: a
foo/bar.ha:
12 let x: int = 10;
13 let y: int = 14;
*14 let q: int = alloc(1234);
15 foobar(x, y, q);
Choose from the following options:
[A]ssert the allocation succeeds (!)
[U]pdate the return value and use error propagation (?)
[E]dit this file
[S]kip
Your choice [a/u/e/s, default 'a']: a
- let q: int = alloc(1234);
+ let q: int = alloc(1234)!;
Apply this change? [y/n]
(and so on)
---
> > Finally, I suspect that removing errors::nomem will be more complicated> > than we anticipate, but we'll see what happens when we cross that bridge.>> Care to elaborate on this?
Mainly because any syscall can in theory return ENOMEM but in practice
only some of them can, and I don't know if that's going to cause
problems or not. Probably not.
What is the plan for the standard library? If you plan on updating
standard library functions to return nomem alongside their current
returns, then it's not only alloc/append/insert that need fixing with
hare ?update.
Uses of functions that currently alloc but do not return an error (such
as strings::dup) will need ! or ? also. Uses of functions that currently
alloc and also return an error (hare::parse::subunit for example) will
need case-by-case fixing that's not so simple.
On Mon Jul 29, 2024 at 12:59 PM EDT, spxtr wrote:
> What is the plan for the standard library? If you plan on updating> standard library functions to return nomem alongside their current> returns, then it's not only alloc/append/insert that need fixing with> hare ?update.>> Uses of functions that currently alloc but do not return an error (such> as strings::dup) will need ! or ? also. Uses of functions that currently> alloc and also return an error (hare::parse::subunit for example) will> need case-by-case fixing that's not so simple.
Ah, true. Updating function calls 100% perfectly does effectively
require lossless AST, to handle different import forms and
shadowing. This is the main reason I wanted to wait for lossless AST,
since the naive approach is imperfect and doesn't correctly handle all
cases.
That being said... it does handle 99% of cases (for recognizing and
changing stdlib identifiers, that is), so that's completely fine.
Definitely better than nothing at all, and shouldn't be a blocker.
As for updating the stdlib: yeah, eventually all functions should be
updated to propagate nomem, but this can be a gradual process. Perhaps
we can start small with functions like strings::dup, while continuing to
assert that allocation won't fail in other functions. Then we can
gradually update the rest of the stdlib to not assert. This minimizes
the amount of stuff that's being broken at once, and also means nomem
can be rolled out much faster.
In general, many stdlib functions abort on errors instead of
propagating, so this isn't a nomem-specific issue.
On Mon, Jul 29, 2024 at 04:51:58PM -0400, Sebastian wrote:
> On Mon Jul 29, 2024 at 12:59 PM EDT, spxtr wrote:> > What is the plan for the standard library? If you plan on updating> > standard library functions to return nomem alongside their current> > returns, then it's not only alloc/append/insert that need fixing with> > hare ?update.> >> > Uses of functions that currently alloc but do not return an error (such> > as strings::dup) will need ! or ? also. Uses of functions that currently> > alloc and also return an error (hare::parse::subunit for example) will> > need case-by-case fixing that's not so simple.> > Ah, true. Updating function calls 100% perfectly does effectively> require lossless AST, to handle different import forms and> shadowing. This is the main reason I wanted to wait for lossless AST,> since the naive approach is imperfect and doesn't correctly handle all> cases.> > That being said... it does handle 99% of cases (for recognizing and> changing stdlib identifiers, that is), so that's completely fine.> Definitely better than nothing at all, and shouldn't be a blocker.> > As for updating the stdlib: yeah, eventually all functions should be> updated to propagate nomem, but this can be a gradual process. Perhaps> we can start small with functions like strings::dup, while continuing to> assert that allocation won't fail in other functions. Then we can> gradually update the rest of the stdlib to not assert. This minimizes> the amount of stuff that's being broken at once, and also means nomem> can be rolled out much faster.
but this will mean that we are breaking hare code again, again, again,
and again over the next coulple of months instead of doing it somewhat
correctly "once and forever". is that the right move?
here's what i would do:
1. implement + upstream harec/spec patches
2. wait some time, let's say a week
3. implement the propagation thing in the stdlib with all functions
where the allocation could fail.
i'm a bit worried that step 3 will not work out that well before there
is more match exhaustivity checking, but i'll have to see.
I might personally be for an approach wherein we do the following:
1. Roll out the compiler change with a small number of stdlib updates,
leaving the rest to use assertions, in one quarterly release
2. In the next quarterly release, roll out the remaining stdlib changes
This is still two breaking changes but it makes both of them smaller and
gives people some time to get used to the new approach.
Thoughts?
On Tue, Jul 30, 2024 at 11:45:14AM +0200, Drew DeVault wrote:
> I might personally be for an approach wherein we do the following:> > 1. Roll out the compiler change with a small number of stdlib updates,> leaving the rest to use assertions, in one quarterly release> 2. In the next quarterly release, roll out the remaining stdlib changes> > This is still two breaking changes but it makes both of them smaller and> gives people some time to get used to the new approach.> > Thoughts?
i think that we should do all at once. first of all, 99.3% of hare
codebases will probably just use allocation failure assertions.
second, if i am updating my codebase, especially if it's one that
wants to handle allocation failures, i don't want to do it two
times. i'd rather like to know *now* what functions might fail, so
that i can change all of my code, instead of having to do it twice.
On Sun, Jul 28, 2024 at 11:27:21AM +0200, Drew DeVault wrote:
> I am not convinced that static append/insert should return nomem instead> of void. It would be easier to eschew this approach if we added a> capacity built-in, but I don't want to tangle it up in this RFC. I'm> okay with moving forward with static append/insert returning nomem, but> expect me to raise the point for future discussion, and if we change our> mind at that point it would mean breaking user code twice; once now and> once then. If no one feels strongly about nomem, I put soft support> behind sticking with static append asserting on failure and punting the> question for a future discussion, in which case we only break it once if> we agree to do nomem at that time.
i don't feel very strongly about this, but i am quite sure this is the
right approach. abort's in built-in's are not the right way to go imo.
this will not be introducing or removing complexity or anything else no
matter what we are doing. however, it has one advantage:
// This function puts something into the queue of a worker.
fn worker_queue(worker: *worker, object: *queue_object) (void | nomem) = {
static append(worker.queue, object)?;
};
in situations where you just want to return nomem if your buffer is full or
something. this is where i think it's useful.
i'd also love if we can expose (and allow setting) the capacity.
cap(), like len(), would be cool. i'd like to work on that next, but
i should stop writing RFC's and start implementing them ;-)