►
From YouTube: 2021-03-23 Lang Team 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
A
All
right,
hello,
everybody
welcome
to
the
triage
meeting.
Let's
start
with
the
action
items
from
previous
meetings,
so
open
action
items
that
don't
currently
show
up
as
done.
We
have
a
lot
we
do
yes,
most
of
them
are
individual
people's
reviews
and
comments
on
specific
items.
So
I
don't
think
we
need
to
go
over
those
in
detail
just
a
reminder
for
them.
A
C
C
A
B
A
I
think
so,
yes,
smaller
steps
as
well
as
that,
we
think
the
larger
item
of
trying
to
do
it
by
default
is
unlikely.
So
it's
purely
could
we
provide
an
opt-in
mechanism
for
people
who
want
early
drop.
A
Okay,
would
someone
like
to
take
a
action
item
to
write
a
brief
explanation
of
that
for
the
mcp
explaining
that
we
would
like
to
see
a
focused
proposal
for
opt-in,
early
drop.
B
So,
at
least
it
says,
drop
guards
discussion,
I'm
going
to
assume
that's
what
this
is.
Probably
yes,
it
could
be.
A
Then,
after
that,
we
don't
have
any
nominated
rfcs.
So
let's
see
we
have
only
one
p
high
issue
nominated.
That's
the
status
on
that
one
for
rapper
c
is
unsound.
On
msvc
targets
is
still
waiting
on
some
further
discussion.
There's
still
some
ongoing
efforts
to
attempt
to
figure
out
if
this
can
be
fixed
compatibly.
A
Msvc
right,
it
is
specific
to
msvc,
and
it
is
also
specific
to
particular
types
used
on
msvc
it
would.
It
is
an
unfortunate
trap
for
people,
because,
if
there's
no
obvious
warning
that
lets,
people
know
that
they're
wandering
into
an
area
where
they
have
to
be
careful.
B
If
we
can
reach
out
to
some
of
the
microsoft
folks
and
see
if
they're
interested
in.
A
I
think
that
would
be
a
really
good
idea
in
the
ideal
world.
We
would
get
someone
from
the
microsoft
rust
team
to
push
for
full
compatibility
here
and
do
the
necessary
evaluation.
A
E
A
The
open
question
is
just:
is
the
current
repressee
sufficiently
ingrained
in
enough
programs
that
the
existing
behavior
is
something
people
rely
on
and
fixing
it
would
break
other
things?
So
I
think
our
two
options
here
would
either
be
try
to
fix
it
compatibly.
If
that
can
be
done
or
if
that
can't
be
done,
we
may
have
to
introduce
a
repair
c,
but
actually
working
and
then
migrate
that
to
be
rep
for
c.
In
a
new
edition.
A
That
would
be
the
obvious
forward
step
to
make
sure
that
in
the
future,
people
can
just
spell
it
represe,
but
either
way.
I
think
we
want
to
fix
this.
The
question
is
just:
can
we
do
it
compatibly
on
all
additions,
or
do
we
need
an
addition?
Boundary.
D
B
A
E
Oh-
and
it
would
just
be
unfortunate,
that
a
naive
cargo
fix
of
a
project
to
edition
2021
or
2024
or,
however,
would
return
all
references
refer,
c
old
or
something.
A
Ideally,
it
could
detect
whether
that's
necessary,
because
we
should
be
able
to
know
whether
reproc
will
actually
affect
the
abi,
at
least
in
most
cases.
There
are
some
exceptions.
E
A
A
B
A
Yeah,
I
don't
think
we
need
to
dig
into
the
weeds
here.
I
think
that
so
felix,
you
said
you
would
take
an
action
item
to
drive
this
with
wesley
ryan
or
some
other
folks
from.
A
A
A
Yeah
no
objection
well.
Taylor.
Do
you
want
to
take
the
action
item
then
to
update
that
one
yeah
I'll?
Do
that
right
now
and
write
a
quick
note
explaining
why.
C
B
A
B
A
C
A
Okay,
we
don't
have
any
nominated
prs
and
issues
for
wrestling
reference,
so
next
up
nominated
prs
and
issues
for
wrestling
rust.
We
have
a
fair
handful
of
these
there's
five
here
before
we
dive
into
the
first
one.
Does
anybody
have
a
item
that
should
be
prioritized
in
case?
We
don't
get
out
through
all
of
these,
or
should
we
just
go
through
them
in
order.
A
A
Someone
also
added
a
note
here
in
the
agenda
that
we
may
want
to
hold
off
until
we
have
lint
levels
defined
in
reports
who
added
that
node
and
would
like
they
like
to
talk
about
that.
I
think.
A
It
looks
like
third
comment
from
the
end
of
might
be
good
to
adjust
the
stabilization
report
to
include
the
current
lint
levels
for
each
of
the
lengths
and
suggested
or
required
new
levels.
B
A
I
would
agree,
I
think
that
we
should
go
ahead
and
fcp
merge
this
and
then,
if
anybody
has
concerns,
they
can
raise
them
as
blockers.
There
is
a
section
called.
B
B
A
A
I'll
take
the
action
item
to
propose
fcp
merge.
A
A
Okay,
while
you're
recording
that
next
up,
we
have
implement
new
lint
for
detecting
buggy
pointer
to
end
casts.
This
is
eight
81789.
B
Yeah
I
nominated
it.
There
was
a
comment
from
varcourt,
which
I
will
copy
and
paste
into
the
notes.
A
A
B
A
Yes,
mark
made
the
comment
that
he
would
prefer
to
still
see
that,
as
as
you
size
as
u-64,
I
think
my
concern.
There
is
the
potential
degree
of
noise
here,
because
there
is
a
fair
bit
of
code
out
there
that
simply
uses
u64,
as
this
is
big
enough
for
a
pointer
on
both
32
and
64-bit
platforms,
and
I
don't
want
to
put
this
on
hold
for
the
mythical
case
of
the
portability.
Lint
of,
let
me
opt
into
assuming
I
don't
have
to
deal
with
128-bit
platforms.
A
I
think
I'd
be
happy
to
discuss
the
other
one
further
as
well.
I
just
think
that
I
would
find
that
one
to
be
a
little
bit
more.
Concerning.
B
I
don't
find
the
128-bit
portability
argument
very
persuasive,
because
it
feels
like
the
kind
of
thing
I'm
trying
to
put
my
feeling
into
words,
but
there's
a
there's,
a
kind
of
thing
where
also
in
c.
I
think
you
have
this
where
there's
like
extreme
portability,
I
mean
you
definitely
have
this
in
c
extreme
portability,
rules
that
nobody
can
actually
follow
in
practice
and
the
end
result
is
people
just
ignore
sort
of
right,
less
portable
than
they
would
be
if
they,
if
you
had
some
sensible
rules
that
target
most
platforms,
it
might
be.
A
B
Yeah,
so
one
thing
I
might
might
be
interesting,
I
guess
I
would
be
happy
with
as
you
64
being
allowed.
It
might
be
interesting
to
talk
about
what,
if
we
did
care
about
this
in
the
future,
what
would
we
do?
I
guess
it
just
comes
down
to.
We
would
start
linting
and
you
could
even
imagine
an
addition.
Change.
A
Right
if
we
ever
introduce
the
portability
lint,
where
you
have
to
explicitly
opt
into
I'm
only
ever
going
to
run
on
64-bit
platforms
or
64
and
32-bit
platforms
or
similar,
then
I
would
have
no
objection
to
making
this
lint
a
worn
by
default
and
then
separately
triggering
everything
off
the
portability
lint.
But
in
this
case
there
is
an
obvious
way
to
solve
the
problem
that
does
not
block
on
that.
So
would
there
be
any
objections
from
folks
in
this
meeting
to
a
consensus
of?
B
No
objection
but
not
going
to
write
it.
I
think
we
are.
I
just
want
to
say
explicitly
that
I
think
we're
making
a
kind
of
precedent
here
which
I'm
happy
with,
though
I
think
we
should
enumerate
it
a
little
more
clearly
that
we
want
lintz
to
target
sort
of
encouraging
practical
portability
with
their
default
settings.
Is
that
correct.
E
A
A
B
Maybe
in
some
embedded
scenarios
yeah
right,
but
I
think
it's
okay
for
them
to
add
an
allow.
A
A
Notes,
I'd
be
happy
to
take
the
actually
on
second
thought.
I
would
like
it
if
someone
else
would
take
the
action
item
for
this
one.
Just
because
I
was
the
person
to
originally
propose
the
u64
exception
here,
and
I
would
appreciate
somebody
else
chiming
in
to
confirm
the
lang
team
consensus,
as
opposed
to
me,
reporting
that
it
happens
to
agree
entirely
with
what
I
would
propose.
A
A
A
That's
82525.
This
was
reported
by
or
proposed
by
ralph
26
days
ago.
The
the
original
blocker
for
this,
I
believe,
was
that
the
adder
of
mechanism
that
we
had
introduced
for
obtaining
raw
addresses
had
not
yet
been
stable,
so
we
didn't
have
anything
for
people
to
replace
it
with
this.
Pr
now
makes
this
a
worn
by
default.
Future
incompatibility
lamp
and
people
can
always
switch
over
to
using
standard
pointer
adder
of.
C
D
B
Was
one
of
the
most
I
just
was
open
about
it?
I
guess
I
think
it
might
be
that
we
just
didn't.
Do
the
follow-up
we
needed
to
do.
I'm
just
checking
the
minutes
real
fast.
A
A
A
So
for
this
one
then
you're
going
to
review
the
functional
correctness
of
the
pr,
and
then
we
agree
on
the
policy,
and
so
as
soon
as
the
function,
the
correctness
is
verified.
Then
we're
going
to
fcp
merge
this.
B
C
B
Okay,
I'll
do
that.
I
think
it's
a
fairly
simple
pr,
though.
A
B
What
this
is
about
is
right.
The
lint
case
is
this
code
that
we
used
to
accept
and
we
were
moved
in
some
rfc
or
other,
or
we
started
warning
or
something
like
that,
and
I
think
the
plan
is
for
edition
2021
to
make
this
a
hard
error.
B
So
while
the
compiler
will
accept
it,
your
code
is
generally
less
compatible
with
the
ecosystem.
If
you
do
use
it,
so
I
actually
think
that's
a
pretty
strong
case
for
deprecating
it
and
we
should
go
ahead
and
make
it
a
warning
on
all
additions.
B
But
that's
the
policy
question
at
hand
and
there's
a
kind
of
a
precedent
around
like
there's,
not
a
soundness
or
other
reason
exactly.
It's
like
a
it's
annoying
for
tooling
to
support
this
reason.
You
could
imagine
this
coming
to
play
with
impulse
and
things
that
are
not
easy
for
ides
to
deal
with,
as
we've
discussed
from
time
to
time
like
nested
items.
A
A
A
good
question
more
than
just
I
think
it's
more
than
just
tools,
don't
accept
it.
If
I
remember
correctly,
I
remember
us
doing
a
change
to
catch
this
in
the
first
place,
where
our
argument
was,
this
was
kind
of
accepted
by
accident,
and
we
just
had
to
keep
accepting
it
because
people
used
it,
but
it
wasn't
actually
intended
to
be
valid
syntax.
That's.
B
B
C
A
A
I
guess
I'm
asking
if
we
were
to
make
this
a
worn
by
default,
would
we
expect
to
see
zero
warnings,
three
warnings
or
300
000
warnings,
depending
on,
if
there's
some
root
crate
that
we're
not
aware
of
that
breaks
horribly?
If
you
do
this,
something.
B
A
B
A
Okay,
so
that's
much
more
compelling
if
this
were
just
going
to
hard
error
in
2021,
that's
different.
If
this
has
been
a
hard
error
for
a
few
years,
then
it's
safe
to
say
that
any
code
that
people
are
using
that
has
this
in
it
has
probably
not
been
maintained
in
a
while
yeah.
D
B
Like
I'm,
I'm
happy
with
it,
because
I
I
want
us
to
push
for
more
consistency
across
editions,
so
like
in
general.
I
think
we
should
this
feels
like
a
deprecation
to
me
like
we
took
this
syntax
away
because
we
thought
it
was
bad.
The
reason
it
was
bad
is
it
made
parsing
more
complicated
for
tooling,
but,
like
that's
fine,
we
want
people
not
to
use
it.
We
should
deprecate
it.
The
this
is
in
contrast
to
like
the
closure,
changing
the
rules,
enclosure
capture.
B
A
Right
yeah,
I
wouldn't
necessarily
want
to
make
this
a
precedent,
for
we
always
push
warnings
back
to
the
earliest
edition
we
can,
but
in
this
case
I
think
it's
relatively
safe
to
do
so,
and
it's
unlikely
to
affect
a
significant
number
of
people,
but
it
will
help
people
catch
things
in
existing
code.
Also.
In
practice,
people
are
unlikely
to
build
new
code
with
the
2015
edition,
which
means
they're,
probably
not
going
to
see
this
lint
to
begin
with.
B
Okay,
now
that
you
mentioned
that
action,
83
167,
I
also
had
let
me
check-
I
think
I
had
some
things
from
the
the
laying
team
meeting
agenda.
I
wanted
to
bring
up
from
the
edition,
but
this
was
one
of
them
and
the
other
was
the
k,
hash
foo
proposal,
which
unfortunately
scott's
not
here,
I'm
going
to
put
it
here.
A
A
A
So
the
proposal
is
to
change
those
intrinsics
to
instead
accept
a
const
generic
and
that
allows
them
to
require
a
constant
argument
without
a
special
case.
A
A
C
C
Well,
then
that's
there's
no
point
because
the
rest
of
the
code
around,
but
it's
not
just
that
the
description
says
that
there's
significant
overhead,
it's
generating
huge
mirror
like
it's
a
it's
a
complexity
burden
in
the
in
the
actual
evaluation
of
the
code,
not
just
the
complexity
of
like
maintaining
the
compiler
itself
right.
A
Sorry,
no,
the
previous
mechanism
was
using
the
large
switch
and
the
mirror
to
sort
that
out
right.
A
A
I'm
understanding
correctly
and
I
may
be
mistaken
here.
I
believe
that
the
internal
mechanism
is
now
using
kant's
generics
and
there
is
just
a
facade
on
top
of
that
that
allows
you
to
use
syntax
that
calls
it
with
an
argument,
as
opposed
to
a
generic
parameter.
C
F
A
Beyond
that,
I
think
the
expectation
here
is
that
the
reason
I
mentioned
this
code
being
fairly
terrible
in
the
compiler
according
to
the
folks
who've
worked
on.
It
is
not
because
we
are
able
to
rip
that
code
out,
but
rather,
if
we
can
compartmentalize
that
code
as
a
legacy
support
mechanism
that
will
never
be
used
for
anything
else,
and
then
we
also
don't
have
to
worry
about.
Is
it
compatible
with
future
things,
because
it
would
be
just
as
easy
to
say?
A
B
B
So
it's
not
just
like
take
the
thing
from
the
end,
but
it
might
be
like
in
this
case
the
oneplus
one
moves
from
the
middle
into
this
list,
which
is
indicated
by
this
positional
argument.
One
one
thing
I
thought
when
I
heard
this
is
that
this
feels
like
like
a
little
bit
of
a
feature
request.
B
But
I
don't
intend
to
block
anything
or
even
try
to
turn
this
into
a
real
proposal,
I'm
just
noting
that
it
might
be
kind
of
cool.
A
A
Is
actually
what
some
third-party
mechanisms
for
this
do
is
use
a
macro
for
this,
rather
than
doing
a
const
code
at
compile
time,
do
you.
A
Third-Party
rust
crates
that
are
doing
some
attempts
at
portable
cimd.
Yes,
when
the
things
like
that
were
brought
in
first
party
into
standard
arch,
then
we
switched
over
to
this
mechanism,
but
third-party
stuff
has
been
using
macros
for
these
types
of
shuffles.
For
some
time.
B
I
have
a
question:
did
the
cindy
there's
like
a
cmd
working
group
in
theory
right
now?
I'm
not
sure
how
active
that
is.
Did
they
have
an
opinion.
A
On
this-
and
I
believe
this
proposal
is
coming
out
of
that
group,
or
at
least
involves
members
of
that
group.
F
C
Right
now
I
understand
wait.
I
thought
you
were
saying,
like
you,
don't
sorry
like
line
eight
in
the
code,
I
thought
you
were
saying
like
looking
at
line
eight
in
the
code
up
above
it
doesn't
look
that
great.
I
wouldn't
want
to
write
that,
but
then
you
said
you'd
be
willing
to
accept
three
writing
the
compiler.
So
now
you're
saying
you'd
be
accepted.
F
B
B
So
what
you
can
say
now
is
that
this
form
the
advantage
of
the
con
generics
form
like
we
definitely
want
it
available
both
for
the
architectural
advantages,
but
also
because
well
I
guess
this
isn't
true.
I
was
going
to
say
also
because
in
generic
code
it
it's
usable,
but
actually
with
the
rewrite.
Probably
that
works
equally
well,
whether
it's
in
generic
code
or
yeah.
C
B
There's
not
much
of
an
advantage
to
doing
this
right.
It's
just
sort
of
that.
The
language
feels
a
bit
smaller.
We
don't,
but
it's
not
really
smaller.
It's
just
like
it
still
part
of
the
spec.
At
the
end
of
the
day
that
that
rusty
legacy
con
generics
is
a
thing
like
you
have
to
have
a
mechanism
for
this.
F
Yeah,
I
I
think
I
would
also
say
that
potentially
it's
worth
noting
that,
even
if
we
could
remove
it,
like
it's
not
obvious
to
me
that
you
know
if
we
were
redesigning
this
from
scratch,
like
part
of
our
goal
with
the
cmd
intrinsics
was
explicitly
matching
what
the
like
intel
compiler.
Does
we
didn't
rewrite?
You
know
their
names
or
anything
else
and
so
saying.
F
Well,
you
know
we'll
we'll
allow
the
like
name,
links
and
so
forth
for
these,
but
right
change
the
parameter
order
for
you
and
force
you
to
use
con's
generics
feels
kind
of.
I
don't
know
un-great.
A
So
here's
an
alternative
suppose
we
did
introduce
a
macro
here
with
exactly
the
same
name
as
the
function
and
you
just
have
to
add
an
exclamation
mark
and
your
code
continues
to
compile
and
it
has
the
arguments
in
the
correct
order
and
then
it
calls
the
underlying
const
generic
rather
than
relying
on
the
legacy
generics
mechanism
would
would
you
mark
or
would
anybody
object
to
that
being
the
proposed
rewrite
so
that
you
don't
have
to
reorder
your
arguments?
A
You
just
have
to
turn
it
into
a
macro,
because
this
kind
of
feels,
like
macro
style,
rewriting
anyway.
What
what
does
that
bias?
You
don't
have
something
that
rewrites
syntax,
that
isn't
a
macro.
F
I
I
don't
know,
I
guess
I
don't
I
I
would
rather
not
introduce
like
200,
plus
macros
or
whatever
it
would
be
for
the
simple
reason
of
change
like
it's
not
actually
rewriting
the
syntax.
Really,
it's
it's
just
a
different
place
of
putting
like
it's
not
changing
the
expression.
It's
not
introducing
any
different
token
form
or
anything
like
it.
It
doesn't
feel
I
don't
know
the
macro
feels
like
extra
noise
and
not
if
we
were
going
back
and
redesigning
them.
Maybe,
but
I
would
rather
just
not
touch
people's
code.
C
I
guess
the
reason
I
can
see
sort
of
for
what
josh
is
saying
here
is,
if
I
were
trying
to
analyze
my
source
code
and
predict
what
my
machine
code
is
going
to
be
like,
I
might
be,
and
I'm
not
realizing
that
this
is
an
intrinsic.
Let's
handle
specific
compiler,
then
at
least
with
a
macro.
I
wouldn't
expect
to
see
you
know
these
things
evaluated
and
emitted
into
the
argument,
positions,
etc.
Before
the
call.
A
Yeah,
if
I'm
remembering
some
of
the
discussions
on
zulip
correctly,
I
believe
this
also
wreaks
havoc
with
code
analysis
or
code
movement
tools
or
similar,
which
have
no
idea
that
this
argument
cannot
be
a
runtime
value.
A
That
would
be
a
difficult
thing
to
teach
a
ide
to
handle.
C
I
wouldn't
want
to
go
to
a
macro
if
there
were
any
chance
that
we
might
do
the
thing
that
nico
was
just
was
sort
of
sketching
out,
though
right
like
if
we
actually
were
gonna
hypothetically
try
to
support
const
parameters
mixed
in
with
the
normal
argument
list,
then
I'd
rather
keep
supporting
this
index.
That's
and
that's
in
there
already,
and
you
know,
try
to
support
it
in
a
full
manner
and
just
expect
third-party
tools
to
also
do
the
same.
A
To
use
this,
I
think
it
we
would
want
it
to
be
on
the
track
towards
that,
as
opposed
to
something
that
only
the
compiler
will
ever
use.
In
only
these
specific
cases
would
we,
when
it's
the
standard
arch
team
has
already
committed
to
the
plan
that
any
future
architectures
will
use
the
const
generics
and
won't
provide
the
legacy
mechanism.
This
is
just
for
x86
generics.
B
Why
did
they
make
that
call?
I
have.
A
B
B
I'm
not
sure
whether
I
think
the
standard
arts
team
is
representative
of
them,
but
that's
kind
of
what
they're
existing
for
like
I,
but
there
is
because
it
feels
like
mark's
argument
not
to
put
mark
on
the
spot,
but
the
argument
the
other
side
is
like
this
is
annoying
for
people
who
are
using
this,
and
I
kind
of
want
to
know
what
people
who
are
using.
It
will
feel
and
think
I
could
see
either
way.
B
I
think
I'd
be
a
little
annoyed,
but
the
the
other
thing
is
that
I
would
feel
like
we
don't
have
to
have
committed
to
creating
a
we.
Don't
we
don't
have
to
know
whether
we
want
to
do
the
thing
I
proposed
above
in
order
to
say
we're
going
to
like.
B
F
Yeah,
I
I
think
I
I
would
also
say
that
it's
not
like
clear
to
me,
at
least
from
from
what
you
said,
josh,
whether
the
stud
arc
team
in
in
making
sort
of
the
call
or
saying
that
you
know
maybe
future
architecture
shouldn't
use
this
old
sort
of
legacy
syntax.
F
It
feels
to
me-
and
I
I
think
from
what
I
recall
from
those
discussions.
It
was
mostly
a
well.
We
don't
want
to
increase
our
burden,
but
it
doesn't
feel
like
it
really
makes
any
difference.
You
know
if
you
had
one
intrinsic,
then
maybe
I
would
say
yeah
we
shouldn't
add
you
know
200
more,
but
I
think
right
now
we
have
at
least
a
couple
dozen
of
these
legacy
ones,
and
so
it's
not
like
we're
really
changing
the
situation,
much
whether
we
add
more
or
not,
in
my
opinion
so
like.
F
B
It
I
mean:
can
we
crystallize
the
there's
like
a
pro
and
a
con
list,
but
I
don't
find
it
expressed
in
the
way
I
want
it
to
like.
I
think,
there's
two
things
at
conflict
here
and
it's
basically
like
like
two
kind
of
tenants,
so
to
speak.
My
my
my
assumption
is
one
of
them
is
that
we
want
const
generics
to
match
the
intel
specification
as
closely
sorry,
not
congenerics.
A
With
a
smaller
surface
area
and
weirdness
expenditure
effectively
right,
we
have
a
like
the
argument
in
favor
of
either
using
const
generics
or
a
macro.
Is
that
both
of
those
things
are
established?
Mechanisms
that
require
that
can
require
you
to
do
things
like
you
must
pass
a
constant
here.
You
must
pass
the
specific
kind
of
syntax
here.
B
But
we
do
have
to
support
that
in
older
code
we
do
but
whether
that
matters-
I
don't
know
it's
really
a
matter
of
like
what
are
we.
In
other
words,
it's
not
about
implementation,
complexity
or
anything
else.
It's
about
or
spec
complexity,
it's
about,
if
I'm
a
user
who
gets
to
only
who
has
the
privilege
of
writing
2021
code.
A
A
C
B
I
I
feel
like
we're.
The
people
who
we
are
really
talking
about
here
are
people
who
will
be
writing
rus,
2021
plus
code,
which
is
kind
of
everybody
who
will
be
using
these
intrinsics
right
like
if
you
don't.
If
we
have
this
feature
and
you
and
nobody
uses
it,
then
you
also
don't
care
that
it
exists
right.
You
only
care
if
you're,
actually
using
these
things
for.
A
C
A
Okay,
if
it
turns
out
that
this
is
sufficiently
annoying
to
people
who
would
write
code
like
this,
that
they
would
be
willing
to
just
make
their
cmd
crates
permanently
use
rust
2018,
so
that
they
can
use
this
syntax
and
then
not
have
to
care
what
we
think.
F
Well,
I
I
would
also
say-
and
we
believe
that
they
won't
won't
right-
you
can
always
use
the
const
generics
form
with.
I
assume
any
of
these
functions,
if
you
want
to
so
really.
What
we're
saying
is
people
will
care
so
much
that
they
want
the
compiler
to
tell
them
to
use
the
conscious
generics
form,
and
I
find
that
really
hard
to
believe,
and
we
can
always
add
a
link
later
so
like
I'm,
not
convinced
that
we
need
to
make
a
decision
today.
In
some
sense.
B
A
So
it
sounds
like
we're
settling
on
a
conclusion
of
we're,
hesitant
to
force
people
in
this
direction
without
direct
user
feedback
from
people
who
are
likely
users
or
existing
users
of
this
mechanism,
saying
that
they
are
either
neutral
or
actively
in
favor
of
const
generics.
F
Yeah-
and
I
would
also
potentially
add
that
I
at
least
feel
that
we
should
not
create
new
intrinsics
or
stabilize
new
intrinsics
that
don't
use
this
mechanism.
F
So
if
we
are
adding
or
stabilizing
new
intrinsics
that
currently
are
either
well,
regardless
of
how
they're
written,
I
would
like
us
to
continue
having
a
uniform
access
to
intrinsics
that
need
a
const
argument
so
that
you
don't
have
to
write.
You
know
some
intrinsics
with
potentially
either
syntax
and
some
intrinsics
only
with
con
generics.
A
C
I'm
sorry
mark.
Can
you
just
clarify
again
what
you
mean
by
that
statement?
I'm
trying
to
understand
you're
saying
you
want
to
make
sure
that
people
can
continue
having
the
non-const
generic
interface
or
you're,
not
saying
that,
because
standard
arch
says
they're
not
going
to
you
providing
that
interface
right.
F
Right
what
I'm
saying
is:
I
think
that
that
we
should
at
least
my
opinion
is
that
stud
art
should
provide
the
new
interface,
the
the
old
interface,
whatever
I
don't
know
how
we
want
to
call
it.
B
F
The
the
either
one
works,
interface
and
and.
F
A
So
I
would
be
inclined
at
the
moment
towards
the
argument
of
let's
not
dig
ourselves
deeper.
Until
we
have
information,
we
can
always
add
new
ways
to
call
the
same
functions.
We
can't
take
them
away
so,
given
that
I
would
be
in
client
I'd,
be
I'd,
be
willing
to
support
the
conclusion
of
we
want
more
user
data
on
what
people
will
feel
like
they
want
to
call
to
decide.
C
Is
a
mistake
in
that
reasoning,
though,
because
if
a
new
api
is
added
and
there's
only
one
way
to
access
it,
people
are
going
to
be
forced
to
use
demons,
they
prefer
not.
To
I
mean
the
style
of
data
you
get
is
actually
people
saying
whether
they
like
it
or
not.
That's
that's.
Okay,
but
if
self
date
is
like
do
a
survey
of
like
how
much
we
see
one
form
use
the
other,
then
we're
gonna
we're
getting
artificial
bias
by
only
having
one
access
point
right.
This.
F
So
I
mean
I'm
happy
to
discuss
again.
I
I
I
don't
feel
like
we're
digging
ourselves
deeper
by
adding
like
I
I
feel
like
we
make
the
situation
actively
worse
by
telling
people
you
have
to
use
the
only
only
the
const
generics
form
for
some
intrinsics,
and
then
you
know
like
I
feel
like
that.
Just
makes
things
worse
and
I
don't
think
it
actually
buys
us
anything.
A
A
So
I.
A
F
I
think
if
a
user
comes
to
us
and
says
they
actively
dislike
the
non-conscious
generics
form,
then
that
changes
my
opinion.
But
if
they
say
they
prefer
the
con
generics
form
but
have
no
opposition
to
the
non-con
generics
form,
then
it
doesn't
actually
matter
because
maybe
something
worried
about
the
second
year.
C
B
So
I
realize
somebody
else
is
affected
by
this.
Besides
folks
using
the
intrinsics
josh
cited
them
earlier,
I'm
back
by
the
way,
obviously
just
got
back
and
then
I
have
to
drop
off,
but
which
is
tool
makers,
because
the
only.
B
C
A
Alternatively,
here's
the
hard-coded
list
of
things
for
which
I
should
treat
them
as
though
they're
macros,
but
yes,
it
would
be
good
to
get
feedback
there
as
well.
If
we
have
people
from
rust,
analyzer
or
from
the
other
ides
and
tools
that
yeah.
This
is
no
problem,
we'll
deal
with
it
with
only
mild
grumbling,
then
that's
useful
information
as
well.
A
So
I'd
be
happy
to
take
the
action
item
of
state
that
we
would
like
to
get
more
information
from
these
two
groups
and
then
I
think,
beyond
that
people
are
welcome
to
chime
in
with
what
they
would
like
to
see
mark.
I
think
that
you
may
want
to
summarize
your
position
as
a
comment.
B
A
A
So
then,
I
will
summarize
the
request
for
information
and
mark
you
can
leave
a
comment
for
your
position
on
keep
sounds
good.
Okay,
then,
let's
go
ahead
and
wrap
up
the
meeting,
and
while
we
pushed
the
time
boundary
a
little
bit,
we
did
get
to
all
of
those
items.
Sorry
nico
that
we
did
not
get
to
kfu,
though
I'll
put
it
on
zulip
sounds
good.
Do
you
want
to
go
ahead
and
end
the
recording
nico.