►
From YouTube: 2021-05-18 Triage 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
All
right,
then,
let's
start
going
down
the
agenda.
We've
got
a
meeting
scheduled
tomorrow
to
do
the
monthly
updates
for
the
various
project
groups
we've
made
pings
and
several
of
them
have
gotten
back
to
us.
A
Then
please
take
a
look
at
any
action
items
that
aren't
done
or
just
aren't
marked
as
done,
and
then
let's
go
on
to
the
pending
proposals,
I'm
assuming
nico,
since
you
have
an
update
right
there
that
you
want
to
say
something
about
this
eager
drop
values.
B
B
So
I
one
of
my
action
items
was
to
which
I
also
didn't
expect
to
get
to
this
week
anyway,
was
to
improve
the
script,
but
for
now
I
figured
we
can
just
manually
page
over
here,
fair
enough.
A
We
you've
got
listed
there
that
there
aren't
any
nominated
rfcs
and
then
are
there
any
of
these.
That
people
want
to
talk
about,
or
do
people
just
want
to
check
boxes,
asynchronously.
C
As
a
procedural
note,
I
do
know
that
there
are
a
couple
that
are
blocked
on
boats.
In
some
sense,
I
don't
know
if
we
should
sort
of
do
something
about
that.
B
Sounds
like
we
should
read
it
and
make
a
judgment,
and
you
can
always
cancel
the
fcp
and
restart
it.
Maybe
we
should
can
someone
take
an
action
item
to
like
go
through
and
nominate
things
on
here
that
seem
like
they
need
to
be
discussed.
A
C
I
I
I'm
happy
to
you
know:
do
a
quick
pass
over
the
rc's.
C
C
A
Let's
do
that,
is
there
a
concern
on
2845
super
trade
item
shadowing
as
well
or
just
unchecked
boxes.
B
Yeah
yeah,
okay,
which
I
haven't
done
yet,
but
I
yeah
okay.
I
have
some
mild
concern
about
this,
but
it's
sort
of
like
it's
just
changing
it's
making
something
significant
that
wasn't
supposed
to
be
significant
before
the
set
of
bounds
that
you
write
and
that
will
affect
the
implementation.
I'm
not
sure
that
I
think
it's
problematic
from
a
user
experience.
Point
of
view,
though,
like
it
makes
a
difference
between
an
elaborated
bound
and
anyway.
B
A
A
Also
84988
is
I
marked
that
as
nominated,
but
I'm
not
seeing
it
show,
oh,
no,
it
did
show
up
in
the
list
down
under
prs
just
was
buried,
so
I
may
bubble
that
one
up
a
little
higher
to
make
sure
we
get
to
it
in
this
meeting.
A
E
Story,
it's
not
nominated,
but
the
keyword,
the
the
reservation,
the
lexical
reservations.
Rfc,
do
we
have
anything
we
need
to
talk
about
about
what
the
details
of
what
that's
semantics
are
supposed
to
be.
I
saw
there
was
a
bunch
of
zulu
conversations
about.
A
It
that
may
be
worth
bringing
up.
Yes,
there
was
some
discussion
about
consistency
and,
in
particular,
consistency
with
the
current
behavior
of
the
r
hash
lexing.
A
The
original
proposal
effectively
said,
put
a
space
on
either
or
both
sides
of
the
hash
in
order
to
avoid
the
reservation
and
that
we
were
only
reserving
token
hash,
some
other
symbol
with
very
specific
syntax
there,
but
our
hash,
even
with
a
space
after
it
is
not
currently
allowed,
and
there
was
some
discussion
asynchronously
on
zulip
about
the
idea
that
token
space
should
still
not
lex
on
the
theory
that
that
would
reserve
anything
starting
with
token
hash.
A
A
B
A
Okay,
we
can
talk
about
that
one
then,
but
if
anybody,
if
nobody
has
any
objections
about
this
item-
or
rather,
if
you
have
any
objections,
there's
a
zoolip
thread
going
on
on
the
edition
channel
to
discuss
this.
So
please
go
ahead
and
make
it
known
there.
If
you
have
a
concern,
I
always
like
the
well.
A
Exactly
the
only
question
is
whether
we
would
be
breaking
something
that
people
care
to
have
keep
working
in
the
next
edition,
and
I
don't
think
we
are
okay.
So
concretely,
can
someone
take
an
action
item
to
report
this
consensus
to
the
appropriate
zoolip
thread
and
say
that
we
discussed
it
today
and
nobody
had
any
objections.
B
B
Okay,
there
was
the
was
it
called
two
tokens
here.
It
is
this.
Is
it
so?
I
don't
think
there's
necessarily
much
to
do
here,
but
I
wanted
to
make
folks
aware
of
it.
So
there's
this
api
from
stir
from
tokenstream
and
the
problem
is
this
just
takes
a
string
and
doesn't
have
any
way
to
say
what
let
me
link
to
this.
It
doesn't
have
any
way
to
indicate
the
addition
from
which
this
string
or
with
which
this
string
should
be
parsed.
B
There
is
the
the
current
behavior
of
the
library.
I
think
I
think
it
will
use
the
addition
of
the
invocation
site
of
the
procedural
macro,
if
I'm
not
mistaken,
which
is
relevant
for
well,
which
is
not
that
relevant
until
we
make
changes,
I
guess
because
it
wasn't
really
relevant
before,
but
that
was.
D
B
B
D
D
E
A
B
Yeah
yeah
sure
the
problem,
the
one
interesting
sort
of
gotcha
here
is
that
many
existing
users
of
this
function
are
procedural.
Macros,
that
wind
up
being
for
some
reason
or
another,
invoked
by
a
macro
rules,
macro
defined
in
another
crate,
and
I
think
that
layer
of
indirection.
B
You
would
imagine
that
the
if,
if
you're
taking
tokens
that
the
user
gave
to
you
you're
getting
the
user's
edition,
that's
kind
of
what
you
wanted,
but
if
you
do
that
in
direction,
you're
actually
getting
the
addition
of
the
crate
which
introduced
the
indirection,
which
may
or
may
not
be
the
crate
that
supplied
those
tokens.
So
luckily,
this
is
like
you
know
a
pretty
small
like
it
only
affects
this,
our
hash
stuff
right.
So
it's
probably
a
case
where
we're
gonna
have
some
weird
addition:
migration
behavior,
but
it's
pretty
small.
C
Raise
that
you
know,
potentially,
the
whole
idea
of
addition,
dependent
lexing
is
is
maybe
not
a
great
idea,
but
I
don't
know
whether
you
know
we
care.
B
D
D
That
is
an
example
of
edition
specific
parsing.
The
addition
specific
lexing
is
a
different
thing,
because
it
depends
on
whether
or
not
separate
tokens
or
not.
A
So
we
don't
determine
whether
something
is
an
identifier
or
a
keyword
at
lexing
time.
B
E
Okay,
and
even
in
even
in
macro
rules,
you
can
take
something
that
you
said
is
a
colon
ident
and
pass
structure
union
and
use
it
as
a
keyword
to
declare
a
struct
and
things
so
yeah.
The
whole
idea
of
what's
a
key
word
lexically
is
a
little
funky.
B
Yeah,
we
don't,
I
thought
the
same
thing
josh,
but
I
think
we
don't.
We
kind
of
we
did
intentionally
design
the
token
stream
parsing
to
sort
of
be
very
generic.
On
the
other
hand,
like
I
don't
know,.
B
C
D
The
impact
of
which
would
be
that
k,
hash
things
and
r
hash
things
now
get
parsed
as
a
single
token
and
are
given
to
macros
as
a
single
token,
rather
than
a
separate
tokens
or
a
single
token,
depending
on
addition.
B
D
E
A
Yeah
we
did
determine
from
a
crater
run
that
k
hash
will
not
break
any
existing
code,
and
so
we
can
make
k
hash
for
keyword
usage,
be
reserved
in
all
editions
and
always
turn
into
a
keyword
which
is
ideal.
It
means
we
don't
have
to
come
up
with
some
unusual,
our
hash
dollar
or
something
for
old
editions,
but
we
did
run
into
conflicts
when
we
tried
to
do
the
general
syntax
reservation.
B
A
In
an
ideal
world
like
proc
macro,
it
would
be
nice
if
you
had
to
declare
a
version
of
that
like
actually
write
a
dependency
because,
unlike
stood,
it
wouldn't
be
the
end
of
the
world.
If
proc
macro
had
a
major
rev
to
drop
an
api.
C
D
E
B
C
E
C
Work
that
I've
been
doing
on
reduction
also
enjoys
the
fact
that
you
can
sort
of
lex
russ
code
independent
of
knowing
anything
about
it.
D
Yeah,
although
I
guess
the
set
of
ides
that
one
do
something
more
than
regex
parsing
for
lexing
and
to
do
do
something
that
that
couldn't
relatively
easily
be
addition
dependent,
I
think,
is
small
or
non-existent,
but
maybe
I
maybe
I'm
wrong.
I
don't
know.
E
E
C
I'm
not
sure
about
that
specific
case,
but
in
terms
of
our
hash
handling
and
the
compiler
in
general,
we
have
quite
a
few
places
where
we
sort
of
guess,
depending
on
various
factors,
whether
the
thing
is
a
raw
identifier
or
it
was
actually
written
as
async
in
a
previous
edition,
and
we
just
sort
of
genuinely
guess
we
insert
the
our
hash
or
not
one
party
print,
for
example,.
B
I
think
there's
I
I
thought
the
token
carried
that
information,
but.
A
Well,
I
don't
think
we're
going
to
solve
this.
The
api
version
of
the
problem
in
this
meeting.
I
think
the
only
question
is:
does
anybody
feel
like
there's
a
a
fatal
flaw
with
doing
edition
dependent
lexing
that
is
worth
hashing
out
right
now,
no
pun
intended
or,
if
not,
then
we
may
want
to
take
it
async
to
discuss
what
the
right
api
for
that
would
look
like,
because,
as
far
as
I
can
tell,
proc
macro
doesn't
currently
have
that
api.
C
I
I
would
be
happy
to
write
up
a
comment
on
the
issue
that
sparked
this
discussion:
eight,
four,
nine,
seven,
nine
asking
peter
chenkov
matt
clatt-
and
I
guess
that's
about
all
I
can
think
of
sort
of
off
the
top
of
the
head
for
sort
of
a
discussion
of
why
we
don't
want
this
state
in
the
lecture
beyond
just
sort
of
you
know
it's
not
there.
Now.
Maybe
we
don't
want
to
introduce
extra
stuff.
E
E
E
E
B
I
think
which
I
remember
how
I
think
that
the
procedural
macros
work
by
white
space
hacks
right,
it's
plausible.
C
A
I
would
also,
as
a
procedural
note,
I
would
observe
we
should
ask
tool
developers
to
elaborate
on
the
potential
downsides
of
addition
dependent
lexing,
but
I
would
also
observe
the
default
there
seems
likely
to
be.
This
will
make
things
more
difficult
and
the
question
is
more:
it's
a
trade-off
rather
than
a
a
full.
You
know
if
they're,
not
thinking
we
should
do
it,
then
we
should
consider
that
feedback.
Rather
than
that,
we
should
treat
that
as
a
veto.
D
I
actually
would
definitely
trust
at
least
matt
clad
to
give
an
honest
response
about
like
whether
more
difficult
means
like
we
have
an
extra.
If
statement
in
two
places
or
like
a
match
statement
somewhere
versus
like
this,
you
know
destroys
laziness
or
something
in
some
critical
way.
Right,
surely.
A
No,
I
completely
agree.
I
think
that
we
could
get
some
good
feedback
in
that
regard.
I
think
I'm
just
suggesting
I
would
want
to
know
what
the
trade-off
is,
and
I
think
I
agree
that
matt
cloud
is
very
likely
to
give
us
the
trade-offs
there.
B
It's
also
true
that,
like
we
discovered
the
k,
hash
foo
has
no
real
impact.
There
is
we
could
explore
the
the
alternatives
are
to.
We
could
reserve
all
ident
hash
ident,
for
example,
and
across.
B
Across
all
editions
just
break
it,
since
it's
not
supposed
to
break
anything,
we
haven't
tested
that
you
only
tested
k
hash.
I
think,
but
we
could
test
that.
A
B
A
A
Okay,
that
doesn't
that
may
have
not
been
the
correct.
A
A
Yeah
often
so,
let's,
if
anybody
has
anything
to
add
on
this,
then
please
speak
now
and
otherwise
I
think
we
should
move
on
to
the
next
item.
B
A
That's
right
so
nominated
prs
and
issues.
We
have
the
tracking
issue
for
rfc
2345
allow
panicking
in
constants.
B
Yeah
I
moved
it
there.
This
is
the
this
is
a
stabilization
issue
that
I
created.
I
think
the
current
status
there's
been
some
discussion.
B
B
I
think
the
I'll
have
to
go
double
check
the
one
issue
that
was
raised,
which
doesn't
bother
me,
but
it's
a
thing
as
if
we
ever
allowed
catching
panics
in
constants
and
people
might
catch
panics.
So
if
you
were
using
them
to
signal
some
kind
of
thing
that
should
definitely
abort
compilation,
it
might
not
work
seems
like
okay,
I
don't
know
I
I
feel
like.
I
would
just
document
that
you
should
be
aware
of
that
and
move
on.
B
C
C
My
impression
is
that
currently
ralph
at
least
feels
that
panics
should
always
sort
of
abort
compilation,
or
at
least
like
that's,
the
current
implemented
behavior,
and
I
do
think
it's
interesting
to
contrast
this
with
what
we
recently
discussed
with
the
to
do
macro
and
unused
warnings
and
stuff
where,
like
it,
it
does
seem
potentially
helpful
to
have
some
way
of
saying
you
know
I
have
a
content,
maybe
it's
not
being
used
or
it's
used,
but,
like
I
don't
care
about
its
value.
C
I
just
don't
want
to
implement
the
function
for
now
and
it's
interesting
that
sort
of
you
know
there
could
be
a
concern
there.
I
guess.
C
Essentially,
yeah,
basically,
like
you
know
I,
this
will
eventually
be
a
string,
but
it
you
know
the
computation
is
hard
and
I
don't
want
to
implement
it
for
now.
E
A
B
Well,
that'll
take
the
compiler
a
little
while
to
get
upset,
but
I
think
like
I'd
like
a
that's
at
least
a.
I
guess
that
is
a
concrete
use
case,
but
I
also
feel
like
in
that
case
you
could.
You
could
just
write
like
this.
C
B
A
Right,
I
think
it
would
be
reasonable
to
have
a
way
to
specify
a
co,
so
I
would
like
to
phrase
it
slightly
differently.
I
think
that
the
thing
that
you're
proposing
that
would
have
a
not
yet
defined
constant
would
be
useful,
and
I
think
maybe
we
should
have
a
proposal
for
that.
I
don't
think
that
should
be
a
blocker
for
being
able
to
panic
in
a
constant.
C
Yeah
that
that
might
well
be,
I
think
that
it
is
worth
noting
that
you
know
with
the
concern
with
catching
panics.
Maybe
the
thing
that
you
know
to
some
extent
could
be
desirable
is
some
sort
of
like
const
panic.
That
does
actually
guarantee
a
compilation
report,
but
that
you
know
has
its
own
complexity.
So
you
know
I
I
don't
object
to
stabilizing.
B
E
I
feel,
like
all
the
good
examples
of
catching
panics,
don't
apply
at
compile
time
right,
because
all
those
quote
unquote
panics
compile
time
are
already
caught
in
the
same
sort
of
sense
of
like
oh,
I
don't
want
the
different
requests
interrupting
each
other.
All
of
the
const
panics
are
caught
by
the
compiler
conceptually
and
don't
interrupt
the
rest
of
compilation
or
anything
so.
A
B
E
E
B
B
Thought
yeah,
okay,
well,
does
someone
want
to
take?
Is
there
any
concrete,
I
mean
move
here,
somebody
could
move
to
merge
up
or
migrate.
E
C
E
With
the,
if
the
com,
if
all
this
conversation
is
resolved
to
yeah
it's
okay,
let's
do
it
then
I'll
propose
merge.
A
C
B
A
Okay,
all
right,
then,
I
think,
let's
move
on
to
the
next
item
and
in
the
meantime,
when
scott
files,
the
fcp
on
that,
then
people
have
more
boxes
to
check.
So
next
up
we
have
tracking
issue
for
unsizing
casts
in
const
fns
there's
an.
C
No,
I
don't
think
so.
I
I
can
nominate
yeah.
A
B
Similarly,
I
don't
think
there's
any
real
updates
here
unless
there
was
some
lib
discussion.
This
is
the
buggy
point.
C
I
think
the
only
thing
is
whether
we
care
to
keep
checking
in.
I
think
that
it
is
potentially
reasonable
that
we
just
nominate
unless
there's
further
activity,
which
I
think
the
loose
next
step
here
from
my
perspective,
is
that
you
know
there's
a
lib
discussion.
Potentially
some
pr's
are
filed
and
once
those
casts
are
added,
the
lint
would
likely
be
sort
of
in
a
better
place
to
recommend
the
casts
in
more
cases,
and
we
can
actually.
A
The
response
from
libs
was
that
we
are
very
amenable
to
getting
proposals
for
concrete
functions
that
serve
specific
subsets
of
as
and
it
would
be
fine
to
have
those
proposed
individually,
and
it
would
also
be
nice
if
somebody
had
a
more
comprehensive
list
of
here
are
the
uses
of
as
and
we'd
like
to
propose
functions
for
almost
all
of
those,
but
that
isn't
a
blocker,
it's
more
of
a
nice
to
have,
and
we
would
take
patches
for
individual
functions
for
portions
of,
as
as
as
they
are
today,.
C
B
A
Also,
as
a
caveat
there,
I
don't
know
that
we'd
want
to
position
that
as
deprecating
as
because
one
possible.
A
Right
exactly
one
bit
of
feedback
from
the
libs
team
was
that,
as
is
really
convenient
for
short
pithy
code,
and
so
it
would
be
nice
if
it
were
limited
to
reasonably
safe
cases
that
did
not
lose
information
rather
than
getting
rid
of
it
entirely.
B
Yeah,
no,
I
take
back
what
I
said.
I
do
think
a
project
group
would
be
fine,
but
I
also
think
I'm
trying
to
think
how
we
can.
I
would
like
to
document
our
intention
to
do
this
and
it
would
be
fine
by
my
view.
That
seems
like
a
good
quest
issue
too
right
of
like
there's
some
work
to
write
out
the
set
of
things
to
be
done
and
then
there's
a
set
of
pr's
to
add
those
apis
and
deprecate
those
slices
of
ads.
They
don't
have
to
all
happen
at
once.
They
can
happen.
It.
C
For
a
design
note
basically
saying
that
yeah,
you
know
we
discussed
here's
the
loose
state,
but
maybe
you
know
there's
not
actually
someone
who
is
willing
to
drive
right,
but
also
you
know,
maybe
there
is,
and
they
literally
copy
paste
the
design
note
essentially
into
a
project
proposal
and
say
I
want
to
do
this.
B
E
A
E
E
E
E
B
B
Right
ideally
do
this
comprehensively,
but
this
is
a
libsteam
approval
question
and
then
once
apis
exist.
Lints
are
welcome.
B
A
B
B
A
A
B
B
I
guess
the
question
is:
did
you
mean
there's
like
a
typo
potential
right
where
you
meant
this,
but
you
you
wound
up
getting
this
weird
thing,
but
then
you're
going
to
get
type
errors.
It
just
seems
kind
of
unlikely.
This
will
actually
compile
and
successfully
pattern
match
when
it's
not
what
you
wanted.
B
A
So
right
yeah,
it
seems
so
unlikely
to
be
what
you
want
that
it
seems
reasonable.
We
could
take
bistri's
suggestion
here
to
not
allow
the
specific
case
of
integer
ranges,
and
then
it
would
be
trivial
to
say
unless
you
parenthesize
them
or
similar
like
if
you,
if
what
you
mean
is
really,
I
want
to
match
a
one
element
array
that
has
a
number
zero
or
greater
in
it.
You
could
write
that
this
way.
E
A
I
don't
think
it's
a
hard
error.
I
think
it's
a
worn
by
default
lint.
This
is
probably
not
what
you
know.
This
may
not
have
been
what
you
wanted
use
a
parenthesis
if
it
is
what
you
wanted
and
we
would
only
need
to
lint
here,
I
think
on
single
element
cases,
because
if
what
you
write
is
something
like
this.
C
B
A
I
will
say
I
do
commonly
wish
to
use
slice
patterns
because
I'm
matching
some
a
slice,
and
I
want
to
say
for
the
single
element
case.
Do
this,
but
the
idea
of
combining
that
with
a
range
I
think,
having
to
use
a
parenthesis.
There
seems
like
what
I
would
want
to
write
anyway.
E
A
Yeah,
this
would
likely
be
a
good
like
first
issue
for
somebody
delving
into
compiler
lintz.
C
C
I
think
maybe
a
good
good
next
step
is
to
say
I
I
can
leave
a
comment,
basically
saying
that
you
know
we
discuss
this.
We
think
that
a
worm
by
default
lamp
for
the
single
element
case
addresses
this
concern.
You
know,
maybe,
if
you
agree,
please
file
an
issue
suggesting
a
lint.
For
that
case,
we
would
be
happy
to
you,
know,
see
it
implemented
and
approve
it.
C
And
that
also
leaves
it
open
to
you
know,
maybe
they
disagree
and
say.
Actually
you
know
you
completely
misread
my
concern
versus
insufficient.
A
A
Sorry,
no
problem,
so
we
discussed
eight
four
nine
eight
eight
previously,
but
there
was
a
follow-up
here,
so
this
is
proposed
for
merge
to
make
target
feature
safe
on
webassembly
and
the
there
are
three
outstanding
check
boxes
on
it.
But
in
particular
I
wanted
to
follow
up
because
ralph
raised
a
concern
and
then
alex
addressed
that
concern.
A
It
sounded
like
the
question
was:
would
llvm
ever
do
optimizations
on
the
basis
of
you're
calling
a
function
that
has
a
different
target
feature
and
I
think
it's
fairly
self-evident
and
alex
is
making
the
case
that,
like
llvm,
can't
make
that
assumption.
That's
a
rust
specific
assumption
that
for
rust
safety
purposes,
llvm
absolutely
allows
you
to
call
a
function
with
a
different
target
feature
after
you've.
Checked
that
you
have
that
target
feature.
A
So
I
don't
think
that
that
concern
is
something
that
we
need
to
block
on,
but
please
feel
free
to
take
a
look
at
alex's,
most
recent
comment
from
two
hours
ago
and
see
if
that
addresses
anything
and
then
we're
looking,
I
think
for
well.
I
think
only
one
person
in
this
meeting
has
the
checkbox
still
unchecked
and
then
taylor
and
felix
are
not
here
but
nico.
If
you
want
to
take
a
look
at
that.
B
A
Right
well,
or
even
if
you
could,
it
would
not
be
unsafe
to
call.
The
premise
is
that
we
have
this
unsafe
on
platforms
like
x86,
because
there
are
legitimate
cases
where
old
processors
misinterpret
new
instructions
and
could
do
arbitrary,
undefined
behavior
that
will
never
apply
on
web
assembly.
Even
if
there
were
a
mechanism
for
differing
instruction
sets,
there
would
be
validation
of
like
either
it
understands
it
or
it
doesn't,
but
it
won't
do
undefined
behavior.
A
B
A
And
the
premise
for
this
is
wanting
to
make
wasm's
intrinsics,
not
unsafe,
or
rather
the
ones
that
don't
have
to
do
with
things
like
raw
pointers.
There
are
still
intrinsics
that
will
be
unsafe
because
they
touch
raw
pointers,
for
example,
but
regular,
like
math,
intrinsic
cindy,
intrinsics,
etc,
should
not
be
unsafe.
Right.
B
Why
do
you
have
those
target
features
in
the
first
place,
and
why
is
there
more
than
one
kind
of,
and
we
know
that
the
wasm
spec
is
evolving,
and
so
are
we
just
not?
I
are
we
just
not
concerned
about
like
I'm
targeting
wasm
1.0,
or
we
expect
sort
of
some
other
semver
to
to
play
that
role.
Do
you
see
what
I'm
saying.
A
Right
so
we
do.
I
think
that
is
the
rationale
for
having
target
features
on
wasm
is
that
you
may
not
wish
to
require
a
new
wasm
interpreter
that
understands
semdi,
for
example,
and
so
though,
so
this
note
here
is
not
actually
the
case.
There
are
wasm
features
that
are
not
understood
by
some
wasm
targets.
E
C
E
A
Well,
that's
interesting,
so
I
think
those
are
two
different
things.
There's
target
feature
1.1
where
you
should
be
able
to
call
safely
call
a
function
that
requires
like
avx
in
a
function
that
already
has
required.
Avx,
then
separately,
there
is,
should
you
be
able
to
safely
call
a
function
that
requires
sse
on
a
platform
that
always
makes
sse
mandatory
like
on
x864?
You
always
have
ssc
and
ssd2.
A
C
A
B
C
E
So
all
right
to
your
comment,
there
josh,
I
assume
there
is
a
target,
feature
sse
or
pick
one
that
actually
works,
because
I'm
not
very
good
at
remembering
target
features
on
x86
and
that
one's
just
always.
So
what
happens
if
you
have
tart
one
of
those
target
features
and
you're
compiling
for
a
x64
target.
A
I
don't
know
if
it
necessarily
even
compiles,
but
if
it
does,
then
it
should
probably
just
be
ignored
like
there
is.
You
always
have
ssc
and
ssc2
on
x8664.
So
if
it
even
allowed
you
to
write
target
feature
sse,
then
it
should
just
be
a
no
up.
A
E
A
You
also
raised
a
point
on
the
issue
which
I
think
is
worth
reiterating
here,
which
is
like
a
lot
of
things
are
safe-ish
in
webassembly,
in
that
they
don't
def
have
undefined
behavior,
but
we
still
don't
necessarily
want
to
make
them
safe,
like
we
don't
make
raw
pointer,
intrinsics
safe
on
web
assembly,
even
though
you
can't
actually
cause
ub
by
invoking
them.
You
can
just
go
scribble
on
things,
but
that
isn't
the
same
thing
here.
This
is
more.
The
underlying
reason
we
had
to
make
it
unsafe
just
doesn't
apply.
A
E
B
A
You
well
also
felix
and
taylor
sure
they're,
not
here.
B
Sure,
okay,
thanks
everyone
all
right!
Thanks
all.