This proposal is APPROVED.

On 2025-01-15 (last night) on IRC, we reached a decision to greenlight
this proposal for implementation.

The following forms were decided:

	if (let var: sometype) ~~~ else ~~~;

	if (let var: sometype = expr) ~~~ else ~~~;

The decision was made in the interest of progress and a strong desire
for the feature to be available.

That's all fine.

+1

Thanks for writing, Lorenz.

Again, I come with a differing vision. I hope this serves as healthy
competition and discourse.

(Reiterating from the "parallelism" RFC) I think mt:: (multitasking) is
a better module name than sync::. Its meaning is more inclusive to
various ideas of... multitasking, not just syncing, which I believe
matters if this module will hold other related submodules. Its shorter,
and a learnable, useful abbreviation.

I suggest we use the popular (established) verbs "acquire()" and
"release()" instead of "lock()" and "unlock()", to distinguish from the
inevitable numerous mentions of "lock" (noun or verb) a programmer will

On Fri Nov 29, 2024 at 8:32 AM GMT, Drew DeVault wrote:
> I am strongly in favor of:
>
> 	if (let x as int) {
> 		// x rebound as int
> 	};
>
> And opposed to
>
> 	ifas (x: int) {
> 		// x rebound as int
> 	};
>
> As you know, I am generally opposed to growing the keyword namespace if

                              RFC SUMMARY

I propose a new language syntax, hereby named "ifas" for the mean time.
The idea is presented here as Hare-pseudocode, in the originally
proposed form with a new keyword "ifas":

	let x: (int | bool) = 42;

	ifas (x: int) x + 1; // the simplest form.

	ifas (x: int) { // this branch is run if `x is int`.
		x + 1;  // within this scope, x is of type int.
	};

On Tue Nov 26, 2024 at 6:06 PM GMT, Willow Barraco wrote:
> The doc says:
>
> > If [name] is a full filepath (begins with '/'), it is used directly instead.
>
> But the function was still prefixing with TZDB_PATH when using an
> absolute path.
>
> This cause a huge problem on Alpine linux, when the user uses the
> setup-timezone without the -i. The setup would copy the timezone file
> from /usr/share/zoneinfo/** to /etc/zoneinfo/**. Meaning date::localnow
> would just fallback to UTC.
>
> Signed-off-by: Willow Barraco <contact@willowbarraco.fr>

On Mon Oct 21, 2024 at 2:22 AM BST, Christy X. Morningstar wrote:
>                                 RFC SUMMARY
>
> This RFC would add a break with value in Hare, allowing for-loops to 
> have result types other than void and never. In effect, this would allow 
> for-loops to be assignable and capable of being evaluated in the same 
> way that compound, match, switch, and if expressions can be.

+1

Achieving symmetry here is good.

> After previous discussion with Ember and some others, I have updated 
> this RFC with the "continue with value" proposal removed. I have 

On Fri Aug 23, 2024 at 12:52 PM BST, Lorenz (xha) wrote:
> On Fri, Aug 23, 2024 at 10:41:48AM +0100, Byron Torres wrote:
> > > On Thu, Aug 22, 2024 at 10:08:07PM +0100, Byron Torres wrote:
> > > > Idea for select statement:
> > > > 
> > > >     select {
> > > >     case let x = <~ch =>
> > > >             ...
> > > >     case ch<~ 1 =>
> > > >             ...
> > > >     case =>  // optional case. selected if all other cases are blocking
> > > >             ...
> > > >     }
> > > > 

On Fri Aug 23, 2024 at 12:52 PM BST, Lorenz (xha) wrote:
> > > > : fiber
> > > > A thread-managed non-preemptive, cooperative (explicitly yielding)
> > > > routine, made up of stackful asymmetric coroutines.
> > > > 
> > > > * Stackful means yields pauses all stacks upto the parent spawner as one
> > > >   large stack.
> > > > 
> > > > * Asymmetric means yield does transfer control to another coroutine
> > > >   directly.
> > > > 
> > > > Conceptually, fibers interleave on the thread they belong to, which
> > > > could be on many cores, which makes little difference to the
> > > > programmer's idea of control flow.

Some rebuttals.

On Fri Aug 23, 2024 at 7:57 AM BST, Lorenz (xha) wrote:
> thank you very much for the feedback! lots of comments inline.
>
> On Thu, Aug 22, 2024 at 10:08:07PM +0100, Byron Torres wrote:
> > : task
> > The most abstract, general idea of a "task".
> > Not a special kind of routine, as Lorenz has suggested.
> > I know some programming languages have adopted this term,
> > and I'm wholly against it. I plead that it does not become a keyword.
> > Tasks as a user defined thing inside an application is OK.
>
> i think that this is a very good term and much better than "fiber"