►
From YouTube: 2021-04-14 Planning Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
There's
a
few
possible
topics
here:
there's
the
guiding
principles
for
the
rest,
language,
wasm,
abi,
lint
oversight.
I
think
this
is
not
really
requiring
a
meeting
at
this
point.
Didn't
we
like.
B
C
A
Yeah,
I
don't
feel
this
is
higher
urgency.
I
would
love
it
if
someone
wants
to
take.
You
know
initiative,
but
but
this
deny
bear
trade
objects.
Didn't
we
can
didn't.
We
vote.
A
Yeah,
okay,
so
there's
a
sort
of
action
item
to
close
this
or
and
link
to
the
I
sort
of
remember
there
being
a
pr
even
but.
A
I
think
okay,
so
good.
One
thing
that
I
just
opened
now
was
generator
planning.
This
came
out
of
talking
to
esteban
over
the
last
couple
days.
Who's
been
kind
of
investigating
generators,
especially
in
the
context
of
the
async
vision,
doc,
because
they
would
help
address
some
of
the
need
for
people
to
interact
with
pin
in
painful
ways,
and
we
were
talking.
A
That's
one
of
the
main
reasons
people
use
pin,
basically
not
the
only
one.
A
So
yeah
the
idea
would
be
to
have
a
meeting
well
esteban.
Do
you
want
to
talk
about
it.
F
Sure
yeah,
so
I
I
I
really
want
to
see
yeah.
I
I
want
to
see
this
dream
into
completion,
but
ideally
this
year.
I
know
that
there
is
a
lot.
There
have
been
a
lot
of
conversations
which
I've
been
digging
into,
but
I
want
to,
it
seems
like
there
hasn't
been
anyone
actually
any
single
driven
driving
force,
and
I
want
to
make
sure
that
we
do
have
someone
potentially
me
pushing
for
it.
I
know
that
there
are
conversations
around
both
semantics
and
syntax
that
we
don't
that.
F
F
Yep-
and
I
I
know
that
there
are-
there
is
at
least
one
rfc
for
generators
open,
but
I
am
guessing
that
we
are
going
to
have
to
write
rfcs
for
the
actual
stabilization
of
the
feature,
because
the
one
that
is
open
doesn't
really
have
a
conversation
about
a
guided
conversation.
To
do
that.
A
Okay,
what
about
let's
go
in
order
to
give
a
little
more
details,
so
the
guiding
principles-
I'm
gonna
just
say
that
I'd
rather
defer
this
until
may.
A
But
I
can
briefly
say:
what's
going
on,
is
that
I
was
working
on
the
async
vision
dock
on
sketching
tenets,
which
I've
now
renamed
the
guiding
principles
based
on
florian's
feedback,
that
nobody
knows
what
tenants
mean
who's,
not
a
which
is
true
or
that
they're.
Not
that
wasn't
quite
how
he
said
it
that
they're
less
friendly
to
non-native
speakers
is
what
his
point
was.
A
The
word
is,
but
in
any
case
for
async
rest
and
I
kind
of
think
the
ones
I
wound
up
with
which
we'll
have
to
get
feedback
on
and
so
forth,
are
kind
of
nice
and
almost
feel
like
actually
principles
for
rust
and
maybe
asyncrust
is
just
sort
of
let's
take
those
principles
and
talk
about
how
they
apply
in
an
async
context,
which
is
kind
of
cool,
and
so
I
wanted
to
talk
about
them
with
the
team,
but
I
think
it's
not
super
urgent
and
there's
only
two
they're,
not
I
haven't
even
finished.
A
A
Yeah,
I
think
there
might
be
room
for
I
have
been
looking
at
that
too.
There
might
be
room
to
add,
supplementing
or
supplementary
material.
A
G
I'll
just
mention
here
for
people
who
aren't
aware
that
I
I
got
another
document,
that's
about
guiding
principles
for
contributors
for
developing
and
adding
to
rust.
As
in,
like
you
know,
the
compiler
itself,
which
is
a
different
topic
and
definitely
doesn't.
I
always
wanted
to
be
overlapped
between
what's
here
and
what's
there
and
it
really
isn't
much
in
case
you're,
curious.
A
You
might
want
something
like
that
too,
but
it's
a
different
doc.
C
Yes,
I
was
the
one
who
proposed
that
this
be
scheduled
as
a
meeting,
so
alex
crichton
is
working
on
providing
a
path
forward
for
webassembly
interoperability.
C
There's
some
details
there
regarding
abi
compatibility,
where
from
me,
where
was
embankment,
had
a
slightly
different
abi
than
the
actual
long-term
webassembly
api
abi,
that's
used
in
other
runtimes
and
they're
trying
to
regularize
that,
and
the
wasm
abi
being
proposed
here
is
a
path
forward
for
that.
For
saying,
here
is
the
abi
that
always
interoperates,
with
whatever
wasm
run
time
you're
running
inside
of
whether
or
not
that's
the
same
as
the
c
abi
for
the
platform?
C
C
So
I
believe
that
this
is
proposing
to
match
the
underlying
llvm
and
wasm
time
and
new
wasm
binden
and
similar
apis,
so
this
is
collaborative
across
quite
a
number
of
webassembly
run
times.
I
believe.
C
C
A
C
So
the
language
proposal
here
is
more
about.
Is
this
a
thing
that
we
want
to
commit
to
to
having
an
abi
named
wasm?
That
has
this
semantic?
What
precisely
the
semantic
is
how
it
would
differ
from
c
on
platforms
that
have
both-
and
this
was
something
I
felt
like
deserved-
a
full
design
meeting
to
discuss,
as
opposed
to
trying
to
handle
it
entirely
asynchronously,
because
it
seemed
like
a
high
bandwidth
discussion
of
what
is
the
wasm
vision
in
general
and
what
are
the
next
steps
and
how
that
will
integrate
into
the
rust
language.
A
C
B
C
A
C
H
A
Well
I'll
say
that
I'm
putting
on
my
2021
planning
hat,
we
already
ruled
this
out
on
the
basis
of
with
the
deadline
for
like
there
should
be
an
accepted
rfc
was
beginning
of
april
and
there's
not
even
a
plan,
much
less
an
accepted
rfc
we're
stretching
it
for
some
places
where
there's
like.
Okay,
it's
not
accepted,
but
it's
written.
C
It
kind
of
works
right
I
agree,
and
given
that
I
don't
think
this
needs
to
be
a
design
meeting
scheduled
in
a
rush.
I
think
that
there
would
be
value
in
getting
the
folks
who
are
working
on
this
to
bring
a
proposal
in,
but
we
could
schedule
that
for
a
design
meeting
in
may
and
try
to
have
it
happen
in
2022
or
so
instead
and
just
plan
on
having
an
opt-in
and
making
it
part
of
the
2024
edition
yeah.
I
haven't
really.
C
But
the
quick
semantic
version
is
for
correctness,
purposes,
drop
really,
should
take,
pin
mute
self
because
it's
incorrect
for
it
to
free
things
that
are
pinned
while
giving
you
a
mute
self
that
violates
some
of
the
guarantees
of
pin,
but,
on
the
other
hand,
fixing
that
would
potentially
require
changing
every
drop
implementation
and
making
everyone
deal
with.
Pin
even
people
who
aren't
otherwise
dealing
with
pinned
types.
So
part
of
the
major
design
back
and
forth
is.
A
C
A
C
Yeah
it's
in
the
edition,
2021
section,
if
we're
all
in
agreement
that
this
shouldn't
happen
for
edition
2021,
we
should
move
that
discussion
and
to
a
place
where
more
people
will
be
able
to
participate
in
it
anyway,
and
it
is
mostly
a
libs
question
in
so
far
as
like
the
drop
implementation
changing,
but
since
drop
is
fundamentally
part
of
the
language
as
well
and
invoked
by
the
language.
It
also
kind
of
is
a
length
thing.
A
C
H
C
So
concretely,
I
gave
alex
a
heads
up
suggesting
that
it
would
need
some
ongoing
preparation
and
that
preparation
was
actually
done
in
preparation
for
us
doing
a
design
planning
meeting
last
week
and
a
design
meeting
this
week.
So
I
believe
this
is
actually
ready
to
be
discussed
and
we
could
schedule
the
wasm
api
for
the
21st
and
then
that
would
let
us
schedule
generators
for
the
28th
and
give
esteban
a
substantial
amount
of
additional
time
for
planning.
C
A
That
sounds
fine,
I
mean
our
usual
rule.
Is
right
should
be
a
doc
the
day
before
I
stand
by
that
right
for
now,
who's
gonna
make
the
doc,
in
this
case.
C
So
for
this
one
I
would
expect
that
to
be
alex
for
generators.
I'd
expect
that
to
be
esteban.
G
G
Well,
I
I
can
do
it
or
niko
can
do
it.
It
sounds
like
either
one's
fine
with
me
all
right,
I'll
I'll.
Do
it
nico?
Okay,
I
said
I
will
reach
out
to
alex
and
try
to
I
mean
the.
A
G
H
G
I
mean
I
mean
it's
in
part,
a
question
of,
like
you
know,
even
giving
an
example
to
look
at.
I
know
that
the
the
most
obvious
example
I
can
think
of
isn't
actually
good
enough.
The
the
the
atomic
thing,
the
meeting
that
I
drove
the
duck
there
wasn't
sufficient
and
the
blog
post
was
too
big
and
the
doc
was
too
skeletal.
I
guess.
A
G
C
Try
not
to
be
too
hard
on
that
document
just
because
you
wrote
it
because
I
think
it
did
produce
a
great
meeting.
I
actually
think
there's
a
really
good
point.
You
just
made
nico,
that's
probably
worth
capturing
in
some
general
guidance
for
these
types
of
design
meeting
documents
that
they
don't
need
to
have
all
the
answers,
because
that's
why
we're
having
the
meeting
they
need
to
have
most
of
the
right
questions.
A
A
H
H
Maybe
even
I
guess
my
question
might
be
like:
why
is
there
a
wasm
api
and
not
you
know
we
don't
have
apis
for
every
other
target,
so
maybe
some
clarification
there,
but
that
might
play
into
the
road
map.
C
H
Okay,
well,
I
guess
links
to
that
or
you
know
copy
paste
or
whatever.
C
A
Yep
for
the
generators
we
kind
of
talked
a
little
bit
about
it
already,
but
this
is
what
we
had
seen
sketch
what
the
open
questions
are
and
present
a
sort
of
overall
plan
for
how
they
will
get
resolved,
and
maybe
some
initial
I.
H
A
It
might
be
useful
to
have
a
straw
person,
not
syntax
and
design,
but
just.
F
A
Cool
all
right
great,
then
felix.
You
can
relay
this
I'll.
Put
this
to
alex
okay,
shall
we
go
through
some
of
the
updates
from
the
active
projects?
A
This
time,
I
did
it
a
little
differently
in
that
I
had
people
update
on
the
actual
tracking
issues,
and
I
asked
them
to
focus
on
these
questions.
What
are
recent
topics?
Exciting
developments,
points
where
the
group
is
stuck
things
like
that
I
meant
to
but
didn't,
but
maybe
I
will
next
time
write
a
cool
script
that
scrapes
those
comments
and
paste
them
in
line,
but
since
I
didn't
do
that,
we'll
just
page
through
so
for
constant
evaluation,
this
is
the
comment,
and
I
guess
it
says.
C
Which
is
currently
in
proposal
to
fcp,
with
three
out
of
five
check
boxes,
yeah.
A
A
There
you
go
taylor
and
felix,
take
a
look
for
async
foundations,
so
there's
the
work
going
on
in
the
async
vision
dock
is,
I
guess
everyone
is
familiar
with
that,
probably
because
I've
been
spamming
you
all
with
it.
Is
that
true,
if
not
talk
to
me
later,.
A
A
Assembling
the
brainstorming
period,
so
we've
got
all
these
status
quo
stories
that
people
have
been
writing
and
there's
some
more
that
go
about
different
problems.
People
have
had
and
now
we're
just
starting
on
sketching
out
shiny
future.
So
definitely
but
these
are
all
the
idea.
Here
is
everybody
who
opens
a
pr
unless
it's
like
a
violation
of
this
that
you
know,
what
do
you
call
it
code
of
conduct
or
something
I'm
gonna
merge
it
sooner
or
later.
A
So
it's
really
every
idea
that
people
have
had
and
then
we're
gonna
do
a
kind
of
phase
where
we
can
try
to
assemble
them,
and
so
that
that's
where
we're
in
now
is
more
of
the
like
brainstorming
period.
So
if
you
read
something
here
and
you're
like
what
this
doesn't
seem
feasible,
that's,
okay,
but
what
I
would
say
is
the
other
thing
is
that
the
shiny
future
is
meant
to
it's
meant
to
be
a
few
years
out,
and
it
doesn't
necessarily
mean
we
know
how
to
do
it.
Yet.
A
It's
kind
of
this
is
what
we'd
really
like
to
try
for,
and
we
think
it's
possible
educated
guests.
So
that's
the
spirit.
I
want
people
to
bring
into
it.
I'd
love
it.
If
people
took
a
look
in
part,
because
I
want
to
do
this
process,
but
so
far
I
feel
really
good
about
it,
and
I
think
it
could
be
really
useful
for
us
in
other
contexts,
but
more
on
that
later.
A
I
think
the
other
thing
which
I
didn't
put
in
this
comment
is
there
are
still
some
well,
for
example,
the
must
not
await
lint,
I
think
the
oh,
that
all
got
merged
and
we're
sort
of
an
implementation
phase
for
those
things
now,
in
fact,
I
think
I
know-
maybe
I
didn't
should
make
a
separate
project
for
it
cost
generics.
A
One
thing
people
might
like
to
know
is
that
there's
now
a
regular
const
generics
meeting
every
tuesday
morning,
it's
more
implementation
focused,
but
if
people
are
interested
you
can
pop
in
it's
on
the
compiler
team
calendar.
I
think
we're
kind
of
working
around
on
the
core
implementation
and
stuff
like
that.
There's
no
real
length
team
involvement
needed,
but
one
recent
discussion
that
didn't
make
it
here
was
about
the
definition
of
equality
and
pattern
matching
which
is
kind
of
a
lengthy
question
and
maybe
will
become
a
design
meeting.
A
C
C
C
C
For
a
little
more
context,
I
believe
the
current
proposal
here
is
to
consider
introducing
an
internal
feature
that
we
can
use
for
just
those
standard
library
types
and
longer
term.
There
may
be
a
proposal
for
non-standard
library
types,
but
there
would
be
such
a
substantial
value
in
doing
this
for
a
stack
of
standard
library
types
that
should
be
sidestepping
the
issue
of
item
potency
for
draft
that
it
might
potentially
work
to
support
it.
For
those.
A
A
Maybe
we
should
always
put
a
little
response.
Well
only
if
there's
something
to
say
denying
trailing,
semicolons
and
expression
macro
bodies
so
seems
like
it's
just
kind
of
blocked.
It's
fine,
safe,
transmute.
A
If
I
recall,
there's
been
a
compiler
team,
mcp
and
they're
doing
some
experimentation
and
the
rfc
got
closed,
they're
going
to
come
back
after
the
experimentation
phase
seems
okay
sounds
good,
so
it's
these
are
all
still
in
the
design
phase.
That
seems
accurate
is
that
true,
this
could
move
implementation
phase
macro
meta
variable
expression,
so
this
is
the
rfc
looks
like
there's
some
ongoing
prototype
work
looks
that
way.
Rfc
229
we've
been
working
pretty
well.
This
feature
kind
of
works.
A
Now
the
we
even
have
the
migration
link,
mostly
working,
we
haven't
implemented
the
auto
trade
stuff
and
the
other
thing
we
haven't
done
that
we
want
to
do
is
do
a
crater
run
to
gather
statistics
on
the
size
of
closures.
Before
and
after
this
change
mark,
we
should
think
about
that
offline.
C
Yep
on
this,
there
was
an
open
question
some
time
ago,
of
what
the
syntax
to
migrate
to
would
be,
for,
if
you
want
to
do,
a
full
capture
was
that
ever
settled.
A
We
decided,
for
the
purposes
of
this
feature,
to
migrate
to
let
underscore
equals
this.
Essentially,
I'm
still
not
very
satisfied
with
that,
and
you
reminded
me
that
I
want
to
re-open
the
capture
clause
discussion,
but
I
think
it's
fine
for
migration.
C
Purposes
actually,
question
on
that:
doesn't
let
underscore
normally
cause
an
immediate
drop,
at
least
today
it
does.
C
C
A
A
Mean
basically,
I
won't
like
if
it's
a
vac
of
u32,
we
we
won't
consider
that
significant,
but
so
so
it
would
drop,
probably
sooner
than
it
would
have
before,
because
it'll
drop
when
the
or
around
the
same
time.
But.
A
G
B
A
B
A
But
within
it
yeah.
A
I
mean
we
do
right,
we
do
borrow
the
place
so
the
semantics
for
let
on
for
let
pattern
equals
expression
is
evaluate
the
expression
to
a
place
if
it's
not
already
one
and
then
match
it
against
the
pattern
and
evaluating
it
produces
the
ampersand
x,
which
then
gets
matched
against
underscore,
which
means
that
nothing
happens
to
it.
So
it
drops
so
it
falls
out
from
the
regular
semantics
is
what
I'm
trying
to
say,
like
you
always
evaluate
for
side
effects,
this
is
kind
of
a
side
effect.
A
Is
there
any,
I
should
have
been
taking
little
notes,
but
I
didn't
that's.
Okay,
there
weren't
any
questions
anyway,
all
right
or
I
mean
any
questions
that
we
did
the
group
needed
to
answer,
never
type
stabilization.
A
This
may
be
worth
talking
about
a
little
bit
mark.
Do
you
want.
H
To
yeah
I
I
can
talk
a
little
bit
about
it,
so
nico
and
I
have
been
sort
of
off
and
on
discussing
it
over
the
past
month,
ish.
The
current
proposal,
which
is
kind
of
summarized
here
and
there's
a
link
to
the
report,
is
to
sort
of
do
even
more
fancy
things
to
hopefully
avoid
the
corner
cases
which
prevent
stabilization
today
due
to
backwards
of
compatibility.
H
The
expectation
is
that
I
will
develop
that
you
know
implementation
in
the
compiler
over
the
next
several
weeks,
so
we
can
do
a
crater
run
and
sort
of
make
sure
that
we're
actually
correct
that
the
new
proposal
is
sufficient
to
cover
the
corner
cases
and
then,
if
true,
that
would
then
allow
us
to
move
forward
on
stabilization
most
likely
either
with
an
rfc
or
some
kind
of
mcp
or
something
like
that.
H
But
I
don't
know.
I
think
the
current
feeling
at
least
in
my
head
is
that
we
shouldn't
discuss
the
specific
proposal
until
that
verification
is
done,
because
we
might
need
to
change
it
again.
Yeah.
A
I
think
the
most
important
points
is
that
we're
not
trying
to
do
anything
to
the
edition,
because
there's
no
point
because
we
need
the
complex
thing
anyway
and
that
we
can
assuming
it
works
out.
We
can
sort
of
add
warnings
in
the
interim
for
crazy
or
for
fallbacks
in
certain
like,
except
for
fallbacks.
We
like
we
can
start
adding
warnings
and
then
make
them
hard
errors
in
the
future
in
a
future
edition.
H
Yeah,
I
think
it
may
be
worth
flagging,
as
a
sort
of
I
don't
know,
concern
of
some
kind
that
you
know.
The
current
trajectory
of
this
feature.
Being
added
does
imply
like
a
significant
expansion
to
fallback
complexity,
but
that
would
potentially
be
limited
to
sort
of
old
editions
in
you
know,
2024
or
beyond
that
even
but
the
concrete
proposal
is
obviously
not
yet
ready,
for
you
know
detailed
review,
but
it
is,
I
think,
worth
noting
that
that's
the
director
we're
on.
A
We
have
c
unwind
on
nightly,
there's
a
small
bug
fix
and
we
haven't
really
done
much
discussion
around
long
jump.
That's
sort
of
my
recollection,
but
but
cny
is
pretty
cool.
C
H
A
Yeah,
I
don't
think
we
need
an
rfc
like
literally
an
rc
only
because
we
would
need
an
rfc
if
we're
going
to
make
changes
for
those
changes,
but
we
did
it.
We
did
make
an
rfc
to
create
this
group,
but
I
think
I've
moved
off
from
I've
decided
that
was
overkill,
but
I
would
like
to
see
some
discussion
about
how
much
we
care
about
long
jump
and
whether
it's
like
worth
trying
to
solve
it
for
context.
What
it
means
is
right
now
the
way
that
the
c
unwind
rfc
that
we
merged
was
targeted.
A
We
kind
of
there's
no
real
correct
way
to
do
long
jump,
that's
to
leave
us
room
to
define
what
the
correct
way
is
and
there's
some
back
and
forth
about
whether
it
should
be
like
if
we
made
it
the
most
obvious
thing
would
be
to
say
you
can
long
jump
over
frames
without
destructors,
but
that
turns
out
to
have
a
chilling
effect
on
optimization
because
it
means
you
can
never
rely
on
functions
to
terminate.
A
C
For
what
it's
worth
unwind
seems
like
something
where
it's
sufficiently
common
to
dinner
deal
with,
that
it's
not
unreasonable
to
have
a
whole
abi
worth
supporting
it
and
to
very
carefully
integrate
it
with
rust,
unwinding
long
jump.
If
that
requires
a
pile
of
annotations
to
support,
it
is
so
incredibly
rare
to
need
to
actively
interoperate
with
that,
it's
more,
it
needs
to
work
at
all.
It
does
not
need
to
be
elegant
in
any
way.
C
C
Right,
I
think
how
given
how
rare
long
jump
is.
We
should
not
sacrifice
any
positive
properties
of
language
or
optimization
in
favor
of
making
long
jump
better.
We
should
just
make
it
possible
with
enough
care
to
long
jump
without
undefined
behavior,
but
if
you
have
to
annotate
a
pile
of
functions
or
even
give
a
special
option
to
the
compiler,
I
don't
think
that
that
would
be
sad.
E
C
Is
that
somehow
different
than
just
exit,
it
only
exits
the
current
thread.
No,
I
realize
that
I
meant
in
terms
of
is
there
some
fundamental
reason
from
a
language
semantic
point
of
view
that
that
is
different
from
just
I'm
terminating
this
line
of
computation,
and
you
don't
know
about
it,
exit
will.
A
A
G
H
I
I
personally
would
feel
a
lot
better,
obviously
not
on
the
lane
team
or
anything,
but
I
would
feel
a
lot
better
with
an
mcp,
basically
saying
hey.
We
would
like
to
explore
this.
I
I
don't
know
rfc,
I
agree,
seems
a
lot,
but
it
feels
like
there
is.
It
is
useful
to
you
know,
call
it
out
explicitly.
Maybe
there's
someone
in
the
community
who
hasn't
been
following.
D
G
G
G
A
Yeah,
I
guess
I
would
like
a
pr
just
so
it's
documented
that
we
set
it
and
we
can
go
back
and
say,
look
here's.
We
said
it.
I'm
not
too
concerned
about
that
like
in
this
instance,
I'm
not
too
concerned
about
controversy,
but
yeah
for
sure.
G
Right,
no,
I'm!
Okay!
I'm
yeah!
It's
just
this!
This
spectrum
between
rfc
mcp
pr.
I
was
just
trying
to
like
hone
in
on
what
is
the
intention
and,
like
niko's
point
of
view,
it
sounds
like
it's
just
like
it's
good
to
like
document
that
this
happened
and
that's
a
pr
is
perfect
for
that,
but
versus
what
mark,
I
think
said,
was
the
idea
of
someone
else
saying.
Well,
I
wasn't
paying
attention
what's
going
on
beforehand,
but
I
might
actually
like
get
involved
and
that's.
A
But
I
think
for
that
the
blog
post
is,
was
already
posted
and
is
probably
a
broader
audience.
So,
okay,
okay,.
A
C
C
E
As
I
said,
as
you
said,
let's
not
get
into
this
in
this
meeting.
It's
quite
a.
E
Detailed
issue:
clubbers,
we
have
a
rough
design,
for
it
needs
to
be
implemented.
Namespace
spacing
whether
we
should
export
the
macro
in
the
prelude
or
in
some
sub
path,
is
in
the
middle
of
a
huge
bike.
Shed
global
asm
is
also
getting
upgraded
to
get
the
same
features
as
awesome,
so
I
maybe
will
be
stabilizing
those
two
together.
I
don't
know.
C
I
do
have
a
question
about
this
list
of
five
items.
To
what
extent
do
these
items
need
to
be
which
of
these
items
need
to
be
stabilization
blockers
as
an
example,
we.
H
C
C
A
A
A
In
addition,
2021
pattern
will
include
the
option
of
having
multiple
patterns
and
we
just
have
to
come
up
with
a
name
for
the
thing
without
multiple
patterns
and
there
have
been
five
proposals,
it
looks
like
nobody's
voted
on
my
little
poll,
which
is
fine.
Maybe
people
should
vote,
but
I'm
curious
if
we
can
do
a
quick
straw
poll
or
something
in
this
meeting,
and
maybe
it
will.
A
C
Did
actually
have
one
discussion
about
that?
Yes,
concretely,
I
think
we
decided
that
it
was
unpleasant
for
whichever
options
ended
up
as
thumbs
down
or
questionable
face,
for
example,
and
that
that
would
generate
some
bias.
A
I
A
I'm
not
too
worked
up
about
this.
Oh.
G
I
G
Yeah,
it's
a
padam,
never
mind.
What's
that.
C
C
C
A
Specific
to
me
like
it's
one
of
many
alternatives,
but
not
necessarily
immediately
understandable
but
specific
in
the
sense
that
I
don't
think
it
would
we'd
have
more
meanings
for
it.
A
I
A
C
Understandable
is
there
a
non-edition
based
name
we
could
use
that
is
patterns
as
they
were
before
this
change.
C
I
mean
I
do
get
the
trade-off
if
we're
going
to
use
it
in
the
future.
It's
confusing
that
cat
2015
is
the
thing
if
you
use,
if
you
want
to
match
a
pattern
inside
a
closure,
whereas
pat,
no
or
at
least
makes
it
very
explicit.
Oh
you
need
to
exclude,
or
because
it
would
conflict
with
putting
or
symbols
around
your
closure.
B
C
B
C
B
C
D
I
I
think,
as
a
user,
I
would
still
be
like
really
curious
why
I
had
to
use
this
other
thing
in
this
particular
place,
whereas
personally
like
having
something
about
the
or
the
pipe
syntax
makes
it
obvious
to
me
like
why
that
is
there,
but
maybe
that's
I
don't
know.
Maybe
we
just
expect
anyone
using
this
to
like
have
to
go
read
about
it.
So.
A
C
For
arguments
between
the
two
of
those,
I
would
actually
even
as
the
person
who
originally
suggested
no-
or
I
think
my
rationale
was
largely.
Oh-
that
tells
me
what
it
you
know
that
it
doesn't
have,
or
so
you
can
put
an
or
after
it,
which
is
what
you
need
in
a
closure.
C
C
C
C
Cool,
can
we
call
this
officially
painted
as
a
bike
shed.
A
Great
okay,
but
all
right
cool.
We
have
three
two
more
minutes,
there's
not
much
left.
What
else
is
there?
Oh
really
fast,
there
was
actually
a
question
on
this
dot.
Dot
equals
thing.
If
you
all
didn't
see
it,
I
don't
know
so.
This
person
has
been
looking
into
stabilizing
these
half
empty
patterns
or
whatever
they're
called,
and
they
sort
of
realized
some
interesting
quirky
interactions
between
or
as
a
pattern
alternative
and
or
as
a
operator
in
an
expression
such
that
things
that
one
might
conceivably
expect
to
work.
A
Don't
work,
I
don't
know,
depends
on
your
point
of
view
and
precedence
like
if
you
write
this,
can
you
see
that
and
at
two
dot
dot,
three
or
four?
That
finds
like
the
other
lines
here.
E
A
My
opinion
was
all
this
stuff
is
fine
because
yeah,
it's
true,
that
the
precedence
is
wacky,
but
that's
like
orthogonal
yeah,.
I
A
D
These
photos
fall
out
from
like
the
general
precedence
structure.
This
also
has
nothing
to
do
with
this
feature
right.
A
For
backwards
compatibility
yeah,
so
I
think
there's
no
problem.
I
think
this
person
is
happy
with
their
being
no
problem.
They
just
wanted
us
to
be
aware
of
it,
and
I
don't
know
what
the
instruction
set
is,
but
since
we
have
no,
we
have
no
more
minutes
all
right,
that's
fine!
This
was
there
before
anyway.