►
From YouTube: Triage Meeting 2020-08-03
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
Hey
everybody,
so
one
thing
I
wanted
to
do
today
is
to
try
to
spend
some
time
working
on
the
pending
mcps,
which
I'm
now
trying
to
rename
to
project
proposals,
because
so
many
people
seem
to
get
confused
about
compiler
versus
lane
team
mcps,
I'm
not
sure,
that's
the
right
move,
maybe
people
are
bound
to
get
confused,
no
matter
what,
but
anyway
I
wanted
to
look
over
some
of
the
ones
that
are
there
and
see
if
we
can't
kind
of
give
feedback
to
the
people
about
whether
they
they're,
realistic
or
not,
and.
A
A
B
A
A
If
we
go
this
way
and
that
would
include
covering
like
for
loop
sugar
and
what
that
might
look
like
and
so
on,
why
don't
we
push
it
for
the
week
after
this,
so
that
we
can
ping
like
boats
and
everybody
else
and
not
be
like
hey
in
two
days
also,
I
know
that
nell
was
gonna,
do
some
more
work
on
the
rfc
this
week,
so
maybe
that
would
be
a
good
time.
A
A
Let's
see,
then
I
guess
I'll
go
back,
I'm
going
to
skip
over
these
incoming
proposals.
For
the
moment.
Oh
my
god,
this
thing
is
driving
me
crazy.
Sorry,
I
have
to
resize
my
window
or
something
because
it
keeps.
A
Being
annoying
okay
in
terms
of
active
design,
I
don't
think
there's
any
constant
evaluation
updates
doesn't
even
know
of
any.
A
A
It
might
be
worth
be
nice
if
we
somebody
for
like
a
brief
summary,
but
maybe
next
time.
A
Okay,
that's
cool
ffi
unwind,
so
we're
now
in
the
implementation
state.
I
merged
the
rsc
last
week
and
I
think
we
have
a
potential
person
who
will
work
on
the
implementation.
A
So
that's
cool,
so
I'll
probably
move
this.
A
I'll
just
keep
giving
verbal
updates,
but
I
don't
think
unless
there's
any
like.
Oh,
I
have
to
move
this
over
to
implementation.
I
think
the
implementation
category
tends
to
not
have
a
lot
to
say,
but
some
of
these
are
one
the
fallback,
so
there's
still
ongoing
work
there
with
blitzer,
which
is
good.
This
was
basically
stalled.
I
don't
know
we
might
need
another
category
for
this
stalled
stuff,
but
there
you
have
it
evaluation,
no
new
updates
on
inline
assembly.
I
assume
we're
still
just
kind
of
waiting
for
people
to
use
it.
A
All
right
we're
waiting
for
people
to
click
their
boxes.
That's
what's
happening.
Those
of
you
whose
names
are
not
checked
here,
consider
owing
and
checking.
B
This
was
one
of
the
ones
that
seems
remarkably,
simple
in
terms
of
this
doesn't
seem
like
it
needs
a
full
project
group
or
similar.
This
might
be
doable
with
just
the
pr.
B
A
A
I'm
also
not
too
comfortable
with
that.
If
we
can
avoid
it,
I
don't
know
how
hard
not.
B
B
D
B
I'll
take
care
of
writing
up
a
comment.
I
I'll
write
a
an
fcp,
merge
and
then
immediately
file.
A
concern
for
needs
feature
gate
just
to
make
sure
that
we
actually
check
that
that
happens
before
it
gets
merged.
A
A
All
righty
before
I
move
on
anyone
any
further
comments.
E
E
So
the
most
important
thing
is
size
of
pointer
to
t
has
a
node
size,
so
that
evaluates
successfully,
even
though
it
mentions
t
and
the
example
given
here
with
full,
currently
evaluates,
because
miri
only
sees
size
of
pointer
to
here
and
does
not
check
and
that
it
that
this
function
might
also
call
size
of
t
which
is
concerning
in
my
opinion.
So
I
would
like
to
forbid
it.
E
Have
we
finished
a
crater
run
on
this?
It's
currently
running,
as
far
as
I
know,.
A
A
E
So
the
new
behavior
checks
right
now
anonymous
constants,
have
to
let
me
quickly
check.
A
A
One
so
this
rfc
for
those
I
don't
know
why
it
was
who
nominated
it
and
why
maybe
it
was
even
me
remember.
I
was
talking
about
it.
Semi-Reasonably
well,
josh
did
okay.
A
I
see
so
this
rfc
says
that
proposes
that
if
you
have
an
unsafe
method
in
a
trait,
you
should
be
able
to
implement
that
trait
with
a
safe
function.
And
the
implication
here
is
that
the
only
meaning.
A
Is
that
you've
got
that
the
caller
has
potentially
extra
safety
criteria
that
they
must
meet
and
not,
for
example,
that
the
callee
must
meet
some
post
condition
that
sort
of
makes
it
unsafe
to
implement.
B
That's
right,
yeah,
so
the
proposal,
it's
exactly
what
you
were
just
saying,
that
the
proposal
was
that
you
don't
have
to
write
unsafe
if
your
function
body
doesn't
need
unsafe,
even
if
the
trait
declared
the
method
as
unsafe
fun,
which
that
first
of
all,
I
think
this
is
related
to
the
thing
we've
been
discussing
more
recently
of
an
unsafe
fin
in
general,
shouldn't
necessarily
make
its
body
unsafe,
and
I
think
that
partly
addresses
this
in
that
the
body
of
the
method
will
not
be
presumed
to
be
unsafe.
B
Even
if
you
do
write
unsafe
fun
so
that
you
don't
have
to
accident,
you
don't
accidentally
use
unsafe
if
you
didn't
want
to.
But
that
aside
it.
Yes,
exactly
that
one.
B
So
that
aside,
I
feel
like
there's
a
different
concern
here,
which
is
suppose
you
defined
a
trait
with
an
unsafe
fun,
and
the
reason
it's
unsafe
is
that
when
you
call
it,
you
are
expecting
the
callee
to
meet
certain
requirements,
and
if
the
callee
doesn't
meet
those
requirements,
then
the
caller
is
going
to
explode.
B
You
know
this
set
of
constraints.
Must
be
met
within
this
data
type
that
it's
constructing,
take
your
pick
and
if
that
is
valid,
if
that's
something
you're
allowed
to
do
which,
whether
it's
allowed
or
not
it's
something
that
people
widely
do.
B
I
have
seen
a
number
of
examples
where
people
define
traits
where
their
methods
are
unsafe
because
of
this.
B
And
so
what
I'd
like
to
know
is
how
would
that
interact
here?
If
you
defined
a
trait
with
an
unsafe
method,
you
would
suddenly
be
able
to
write
safe
code
that,
because
it
doesn't
meet
the
expectations
of
some
other
code
elsewhere,
would
cause
some
kind
of
breakage,
and
you
never
had
to
write
unsafe
yourself.
D
So
I
thought
that
if
there
was
an
expectation
on
what
the
implementation
of
the
trait
would
do,
that
that
was
an
unsafe
trade,
not
an
unsafe
method
on
the
trade.
D
That
an
unsafe
method
was
that
there
are
preconditions
that
are
not
checked
by
the
type
system,
that
the
caller
must
uphold,
that
the
method
itself
always
has
to
do
sound
things
based
on
the
preconditions
that
it
knows
about
either
because
of
the
type
system
or
because
they
were
in
its
safety
section
and
the
caller
promised
to
uphold
them.
B
E
B
Fun
means
the
caller
is
prepared
to
meet
requirements
and
call
this
an
unsafe
block,
because
so
it's
allowed
to
do
unsafe
things,
but
if
that,
if
that
is
the
case,
okay,
I
see
what
you're
saying
if
it
were
just
that
you
want
to
do
unsafe
things,
you
could
use
an
unsafe
block
inside
a
safe
fun.
B
This
is
the
caller
needs
to
meet
certain
requirements
in
order
to
call
the
function.
So
it's
an
unsafe
fun
so
that
you
know
you
have
to
write
unsafe
around
it
and
you
have
to
meet
its
preconditions.
A
D
You
don't
depend
on
any
of
the
safety
things
that
the
caller
is
promising,
so
you
could
mark
it
as
not
unsafe
because
you're
not
there
are
no
non-type
system
prerequisites,
preconditions
that
the
caller
needs
to
uphold.
A
B
For
this
interpretation,
you
know
it's
also
nightly
only
so
it
is
something
we
could
change
if
we
needed
to
yeah
right.
A
Yeah,
so
this
is
a
good
example
of
what
I
was
going
to
say,
which
is
that
we
don't
currently
have
a
way
to
make
a
trait
that
is
like
conditionally
unsafe
to
implement,
which
is,
I
think,
what
people
sometimes
want
so
like
they
would
want
something
where
it
says.
If
you
don't
implement
size,
hint
iterator
is
safe,
but
if
you
do,
it
is
unsafe,
and
that
was
the
idea
of
trusted.
Land
was
to
kind
of.
A
This
to
work
around
that
essentially
so,
but
I
think
I
think
we
should
just
go
like.
I
think
it's
in
I've
changed
my
mind
on
this
in
the
past,
but
I
think
I
was
just
wrong.
It
seems
pretty
clear
to
me
that
the
scots
understanding
is
sort
of
just
correct
and
the
language
people
may
use
it
another
way.
But
that
feels
wrong
to
me
and
maybe
we
should
try
to
provide
them
a
better
tool
than
like
a
unsafe
trait,
or
at
least
just
talk
more
about
the
pattern.
A
C
C
D
A
D
It's
sort
of
we've
had
a
whole
bunch
of
things
down.
This
line
of,
like
people
have
talked
about
trusted
ord
for
your
sort
is
actually
so.
Your
ord
is
actually
an
ordering,
not
some
garbage
so
that
we
could
actually
rely
on
it
and
sort,
because,
apparently,
you
could
make
sort
like
two
percent
faster
by
trusting
that
or
something.
A
D
D
That
said,
you
can
define
the
impul
of
the
method
in
your
trait
as
const,
even
if
the
trait
itself
didn't
say
that
the
method
on
the
trait
was
const,
like
you
could
imagine,
saying
hey,
I
am
implying
default
for
my
thing
and
the
default
method
is
a
const
fun,
even
though
the
trait
does
not
stop
now.
I
don't
know
that
we
want
to
do
that,
but,
as
a
example,
it's
sort
of
the
same
thing
to
me
of
my
impul
is
allowed
to
promise
something
stronger
than
what
the
trait
actually
said.
It
was.
D
D
B
Right,
I
believe
the
the
rfc
here
may
have
punted
on
the
question
of.
If
you
know
what
the
type
is-
and
you
know
its
implementation
has
a
safe
thing
here,
can
you
call
it
without
an
unsafe
block?
I
think
that
it
just
punted
and
said
you
know
if,
generally
speaking,
you
know
that
it
has
the
trait
and
the
trait
says
it's
unsafe,
so
you
have
to
assume
it's
unsafe.
B
Now
there
is
an
interesting
example
here
of
an
analogy
to
const,
which
is
that
not
unsafe
is
almost
a
similar
parallel
hierarchy
of.
If
you
want
to
call
it
using
what's
in
the
trait,
then
you
can
and
the
fact
that
you're
allowed
to
omit
unsafe,
meaning
make
it
safe
is
similar
to
the
idea
that
you
can
add
const.
In
both
cases,
it
means
you're
implementing
something
slightly
stricter
than
the
trait
and
in
theory
you
could
ask
for
impulse
of
that
that
are
compliant
with
the
stricter
version.
A
That
would
be
I'm
sort
of
inclined
to.
A
I
don't
know
I
guess
I
was
going
to
say
to
close
this
rc,
but
not
because
I
disagree
with
that.
I
actually
like
it,
although
I
don't
know
how
you
think
about
that
last
part,
but
I
do
want
to
say
there's
another
precedent
here.
If
I
remember,
which
is
that
I
think
you
can
you're
allowed
to
have
region
or
lifetime
annotations
that
are
more
accepting
than
like
this
says
it
will.
B
You
know
it's,
this
is
a
covariance
contravariance
kind
of
thing
of
you're
allowed
to
be
more
accepting
than
your
apparent
trait
right,
yeah.
B
So
you
could,
for
example,
also
say
no
I'll
take
something
that's
static
rather
than
something
that
has
to
be
limited.
A
A
Right
right
and
we
used
to
do
we
actually
used
to
do
what
the
rsc
proposes
and
actually
take
advantage
of
this
when
type
checking.
But
we
stopped
doing
that
at
some
point
because
it
was
a
pain
in
the
neck.
I
don't
know
if
I
like
that
part
of
the
rc.
I
think
I'd
probably
go
one
step
at
a
time,
but
just
because
I
there's
implementation
and
considerations
and
I'd
want
to
wait
until
we've
got
a
nicer,
cleaner
set
up
for
how
we
handle
all
that
stuff.
D
A
D
A
D
B
Yeah,
that's
a
good
point
in
the
case
of
kant's.
To
the
same
would
be
true
if
you
went
from
it
being
const
to
it
being
non-const.
That
would
potentially
be
a
breaking
change,
but,
on
the
other
hand,
that's
part
of
why
we've
talked
about
having
you
write
it
as
like
impul
const,
something
rather
than
just
filling
in
a
const
fund
in
the
trade
and
having
that
magically
propagate.
A
B
D
A
A
It's
not
like
it's
hard
to
implement
at
least
the
first
half,
but
I
mean
if
we
just
allowed
it
to
align
the
unsafe
keyword,
then
we
do
definitively
declare
the
meaning
of
unsafe
on
a
method
and
we
don't
get
ourselves
into
any
december
hurdles.
Yet
I
guess
well.
Maybe
we
would
want
to
do
that
in
one
step,
because
if
we
tried
to
later
make
it
something
you
can
take
advantage
of,
then
we're
sort
of
changing
the
december
meaning
of
existing
code.
D
A
D
B
I
would
agree
with
postpone,
I
would
also
say,
given
that
we
just
talked
through
and
managed
to
figure
out
a
very
difficult
question
of,
or
at
least
a
like
non-well-documented
question
about,
does
unsa
what
does
unsafe
fun
mean
versus
what
is
unsafe,
trait
mean.
I
agree
completely
with
scott's
interpretation
of
that.
I
think
that
was
not
at
all
obvious
and
we
should
document
it.
So,
even
if
we're
postponing
the
rfc,
I
think
it
is
worth
explicitly
documenting
that
that
was
the
consensus
we
agreed
on
and
putting
that
somewhere.
A
So
anything
on
this
rc
bus,
that's
surprising,
to
people!
Let's
talk
about
this
content
there
it's
project
charter,
so
we
have
a
few.
A
The
current
process
is
that
creating
a
project
group
is
a
kind
of
commitment
on
the
part
of
the
ling
team
that
we
think
this
is
a
good
idea,
and
so
we
decided
to
run
with
rfc
bot
fcp
merge-
and
this
is
the
first
instance
of
trying
that
I
guess
bastion
is
here,
but
this
is
the
const
generics
charter.
The
idea
is
to
make
a
project
group
that
will
pursue
constant
generics,
starting
with
the
goal
of
this
minimal,
subset
and
working
out.
What
we
feel
whatever
they
they
slash.
A
A
Yep?
I
don't
think
in
this
case
there
there
was
no
mcp
and
at
least
no
lane
team
one,
but
that's
okay.
We
all
got
the
idea,
there's
a
bunch
of
other
stuff,
so
check
your
boxes
if
you're
good
with
that,
I
think
one
thing-
that's
not
in
this
charter
by
the
way
is
the
initial
people
involved.
A
Bastian
that
you
were
gonna
lead
it
I
would
be
willing
to
liaison.
I
guess
I
may
be
both
it's
both
story.
A
A
You
know
something
that's
where
we
have
a
huge
backlog,
so
I
wanted
to
try
and
get
on
top.
My
thought
was
that
we
could
look
at
these
and
try
to
write
up
like
answer
a
few
questions
about
them
and
or
leave
some
thoughts,
and
basically,
what
we
should
leave
with
this
meeting
is
either
a
sense
that
we
like
do
or
don't
think.
This
is
a
good
idea,
or
maybe
some
suggestions
for
possible
liaisons
in
which
we
have
some
they
may
or
may
not
like.
A
A
A
B
Can
you
can
you
elaborate
a
little
bit
on
it.
A
A
That's
implemented
for
all
function,
types,
all
fn
types,
and
the
reason
is
that
you
can't
write
an
impul.
That
applies
to
all
those
types
and
we
have
no
features
that
would
enable
you
to
do
so
because
you
can't
be
generic
over
abis
or
the
number
of
parameters
or
the
kind
of
lifetime
bindings,
but-
and
we
frequently
find
things
like
people
who
want
to
treat
function,
pointers
as
kind
of
integers,
basically
like
board
or
partial
eq,
or
clone
all
these
different
traits
right
now.
A
I
think
a
lot
of
those
are
built
in
the
compiler,
but
the
hope
would
be
that
if
we
have
a
built-in
trait
that's
fundamental,
that's
important,
then
you
could
write
more
of
this
stuff
in
library
code
and
what
you
commonly
see
today
is
stuff
like
this,
where
people
kind
of
implement
for
all
the
possible
variations
that
they
can
come
up
with
or
this
one
you
know.
So
I
guess
we
don't
actually
build
it
in
the
compiler.
I
don't
know,
I
think
we
do
it
for
copying
clone
because
we
absolutely
have
to.
A
But
so
one
problem
is
that
one
one
motivation
here
is
that
we're
working
on
improving
how
the
compiler
handles
higher
ranked
lifetimes
and
some
of
these
patterns
may
stop
compiling
that
they
compile
so
it'll,
be
nice
to
have
something
for
people
to
move
to.
In
that
case,
because
some
of
them
only
compiled
by
accident
kind
of.
D
B
B
B
A
A
Closure
types
would
be
okay,
but
if
you
wanted
to
implement
it
for
arbitrary
types,
I
think
there's
some.
Why
do
I
have
concerns?
Well
yeah?
I
don't.
If
it's
some
today,
you
can't
manually
implement
fn
and
fn
mute
and
so
on,
but
eventually
I
think
we
would
expect
you
to
be
able
to,
and
I
don't
know.
A
But
anyway,
it's
something
we
could
explore
like
I'm,
not
too
wedded
to
the
details.
There
was
a
like.
I
said
some
people
had
some
close
changes
that
would
allow
you
to
do
a
little
more
than
just
get
an
integer.
That
represents
the
function,
I
think,
partly
to
address
wanting
to
be
generic
or
epi.
In
some
cases,.
E
B
A
D
I
think
part
of
your
the
answer
to
why
not
f
capital,
f
n
is
that
it
hasn't.
Has
you
size
method
in
the
trade.
A
A
But
yes,
that's
part
of
the
reason
you
could
have
a
method
for
ord
and
a
method
for
eq
and
stuff
like
that.
A
A
It
doesn't
really
correspond
to
our
priorities.
I
wouldn't
say
except
basically,
unless
if
the
compiler
is
making
changes
that
break
people's
code,
then
this
goes
up
in
priority
and
because
of
that
until
then
it
seems
fairly
low.
That's
my
take
is
that
right.
A
Yeah
we
could
certainly
it
would
need
still
some
lane
team
action,
but
yeah.
This
is
kind
of
a
commitment
to
that
happening,
but
yeah.
B
I
do
think
that
there's
long
term,
we
really
want
some
kind
of
overarching
fun
trait
that
takes
these
things
into
account
and
can
give
you
pointers
and
can
also
let
you
call
things
and
similar,
but
that
would
wait
on
periodic
generics
and
it's
a
question
of
do.
We
want
the?
How
urgently
do
we
need
this
intermediate
step.
A
So
let
me
try
to
summarize
these
points.
There
is
a
problem
here,
but
it
might
be
nice
if
we
were
able
to
permit
more
operations,
then
just
treat
as
by
the
way.
I
saw
some
notes
here
that
it
looks
like
you
could
also
just
support
as
you
size,
but
it
would
cause
us
to
reify.
The
function
point
should
be
kind
of
neat,
but.
A
Yeah
maybe
I
agree
that
would
be
nice
all
things
being
equal,
I
don't
know,
but
then,
if
the
compiler
changes
wind
up
sort
of
breaking
people's
code,
this
goes
up
in
priority.
A
Right,
I
think
we're
gonna
do
that.
I
want
to
move
to
another
one.
I'm
closing
it's
my
thing,
maybe
we'll
open
it
later.
So
the
next
oldest
one
portable,
simple
project
group,
so
some
background
here-
is
that
henry
bonan
has
been
trying
to
encourage
us
to
get
portable
cindy
for
quite
some
time.
There's
a
lot
of
details
here
in
this
which
I
won't
go
into,
but.
A
Basically,
the
idea
is
that
llvm
supports
kind
of
somebody
that
compiles
down
to
different
targets
in
different
ways
and
there's
this
packed
cmd
crate
that
exists
where
people
are
trying
to
take
advantage
of
it.
Using
some
unstable
features.
Is
that
right?
So
currently
it
works
by
being
generic
over
array
types.
I
think,
as
you
can
see
here,
and
so
the
proposal
is
to
explore
this
and
see
what
it
takes
to
support
this
in
rust.
There's
a
lot
of
detailed
background.
A
Some
hands
up
and
hearts,
I
think,
might
I
want
to
see
this
work
go
forward,
but
I,
if
we
jump
to
my
little
like
and
maybe
I'll,
try
typing
in
some
of
this
now
we're
almost
out
of
time.
A
But
maybe
we
have
time
for
one
more,
but
I'm
concerned
that,
like
we
don't
have
the
right,
we
have
to
figure
out
who
the
right
people
are
to
work
in
this
group,
because
I
think
there
are
maybe
even
a
few
different
approaches
over
time
and
I'm
concerned
we
sort
of
don't
have
the
like
available
bandwidth
to
really
manage
this
work
very
well,
so
I
would
sort
of
be
inclined
to
either
close
or,
if
there's
or
maybe
postpone,
someone's
queue
of
like
we'll
get
to
it.
I'm
curious
to
hear
what
other
people
feel.
B
A
B
B
So
I
do
actually
agree
entirely
with
that
aspect
of
this
particular
proposal
in
charter
that
there's
a
lot
of
things
to
be
a
lot
of
variations
on
how
you
could
do
7d.
But
I
think
that
having
fixed
with
cmd
at
various
various
specific
widths
is
valuable
and
trying
to
do
full
variable
with
cmd
is
something
that
should
be
handled
separately.
B
I
think
there's
value
in
both,
I
think
there's
value
in
both,
but
I
think
the
proposal
here,
as
far
as
I
can
tell
is
we
should
have
128-bit
cmd,
256-bit,
70
and
so
on,
and
we
should
just
implement
it
everywhere.
We
can,
even
if
we
have
to
polyfill
the
256-bit
on
places
that
only
have
128
bit
and
so
on,
and
I
think
that
is
the
right
approach.
I
think
that's.
B
I
think
the
primary
concern
here
would
be
things
like
it's
a
lot
of
little
details
like
what
are
the
correct,
vector
types
to
use.
Would
they
be
compatible
with
the
types
we
already
have?
Can
you
move
between
them
without
needing
a
transmute?
Could
you
share
the
types
in
the
first
place?
B
E
A
But
you
know
the
fact
that
it's
not
actually
on
our
list
is
also
like
a
somewhat
lowers
it
in
my
view,
like
it's
not
a
perfect
fit
now
that
doesn't
really
mean
anything
because
we
made
up
those
priorities,
but
I
it
means
something,
but
maybe
we
feel
like
we
it's
so
important.
We
should
do
it
anyway,
but.
D
A
D
B
Right
so
there's
actually
an
interesting
notion
here.
On
the
one
hand,
you
could
do
this
by
using
entirely
the
architecture
intrinsics
that
are
already
exposed
and
implement
this
entirely
as
a
library-
and
if
that
were
the
case,
then
this
wouldn't
really
need
any
lang.
Support
the
other
approach
and
the
one
that
this
is
proposing
is
to
use
lovm
intrinsics
that
are
in
some
way
portable-ish
and
are
designed
to
compile
to
the
right.
B
Instructions
on
different
platforms,
rather
than
re-implementing
those
llvm
intrinsics.
The
upshot
is,
we
don't
have
to
re-implement
a
bunch
of
intrinsics.
The
downside
is,
we
depend
on
the
llvm
intrinsics,
which
are
inherently
unstable
and
nightly
only
and
probably
always
will
be,
and
as
far
as
I
can
tell,
the
primary
motivation
for
this
proposal
was
well.
We
want
to
keep
using
the
aloe
vm
intrinsics,
which
we
know
will
never
be
stable
and
we
want
to
be
stable.
So,
let's
become
part
of
standards,
so
we
can
use
nightly
and
be
stable
and
right.
E
B
D
So
I
I
see
it
so
I
don't
disagree
with
anything.
You
said
about
the
implementation
possibilities
there,
I'm
going
to
make
two
statements
about
that.
First,
if,
from
a
observer's
perspective,
you
cannot
tell
based
on
using
these
portable
cimd
types,
whether
they
are
implemented
using
lvm
intrinsics
or
the
existing
architecture-specific
stuff
with
cfgs,
then
our
I
could
make
an
argument
that
this
isn't
actually
a
laying
question
at
all.
D
D
For
don't
think
it's
that
I
want
to
use.
I
like,
I
don't
want
this,
because
I
want
to
use
the
cindy
instruction,
the
like
lvm7d
vector
types
internally.
I
want
this
because
I
don't
like
using
intrinsics
and
I
would
like
to
use
you
know
the
add
trait
to
add
things
or
something
and
have
a
rusty
api.
On
top
of
all
this,
that
doesn't
look
like
the
intrinsics
and
isn't
platform
specific
so
that
I
can
just
write
code
and
have
it
do
a
good
thing.
A
So
it's
four
o'clock,
and
so
it
is
here
I
don't
know
what's
coming
out
of
this,
but
I
it
seems
like
we
had
some
good
thoughts.
A
lot
more
feedback
it'd
be
great.
If
someone
could
write
some
of
it
up,
but
I'm
kind
of
circling
back
to
do.
A
We
have
a
liaison
and
how
strong
do
we
feel
motivated
like
it
seems
obvious
that
there's
a
lot
of
discussion
to
be
had
maybe
we'll
revisit
it
next
week,
but
I
think
those
are
the
questions
we
have
to
put
a
little
thought
into
this
somebody.
A
Oh
slash
does
anyone
feel
like,
even
if
someone
is
that
it's
too
much
work
or
not
there's
so
it's
going
to
have
implications
for
the
rest
of
the
team
that
would
hold
it
back.
D
B
B
You
know
handing
the
rest
of
this
to
the
libs
team
and
just
hearing
back
when
it's
done
like
are
our
requirements
are
related
to
the
use
of
intrinsics
and
the
potential
exposure
to
of
those
intrinsics
beyond
that
and
beyond
that
we're
not
especially
concerned
so
we're
happy
to
delegate
the
rest
to
libs.
If
somebody
wants
to
put
that
into
the
comment,
I
I
personally
would
agree
with
that.
B
Any
other
thoughts
on
other
lang
team
considerations.
There.
A
D
B
B
The
idea
of
being
tied
completely
to
llvm,
so
I
think
that's
where
I
would
put
that
is
it's
a
quality
of
implementation
thing.
But
if
the
implementation
is
such
that
it
can't
work
anywhere
but
lovm,
then
there's
a
consideration
there
beyond
libs.
A
All
right,
I
think
we
gotta
end
this
call
I'm
not
sure
what
the
takeaway
is.
Maybe
there
just
isn't
one
yet,
but
I
I
think
this
idea
of
we
should
think
about
I'll,
put
I'll,
try
to
post
a
summary
I'll
volunteer
for
that,
but
in
particular
weighing
the
idea
of
maybe
we
can
ping
the
libs
folks
and
see
if
they're
interested
and
what
they
think
if
there's
somebody
that
they
also
might
have
an
idea
of
like
what
other
approaches
are
out
there.