►
From YouTube: 2021-01-19 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
And
we're
recording
all
right,
anyone
have
any
opens
to
add
to
the
meeting
before
we
go
through.
A
A
A
It
sounds
like
this
is
underway
felix.
It
looks
like
you're
driving
some
of
this
from
the
language
team's
perspective.
Can
you
the.
A
Right,
I
was
about
to
ask
if
you
have
any
updates
on
this
item.
C
D
A
Or
something
I
think
it
may
have
been
accepted
just
not
fully.
Procedurally,
there
is
already
a
tracking
issue
for
it
and
it's
in
the
process
of
being
implemented
now.
A
So
I
think
that
that
was
added
after
the
after
your
second
felix,
so
I
believe
it
has
been,
and
just
somebody
needs
to
wrangle
the
actual
lane
team
issue,
70.
yeah
felix.
Would
you
like
to
take
care
of
that.
A
Yeah
closed
and
a
tracking
issue:
well,
there
is
already
a
tracking
issue.
B
A
There
is
a
to
announce,
usually
that
suggests
that
we
should
create
a
blog
post
talking
about
it
and,
despite
this
being
a
fairly
minor
change,
we
may
wish
to
go
ahead
and
do
that.
Okay,.
D
A
Something
together,
so
that's
something
where
either
you
or
aaron
may
want
to
put
something
together.
D
Just
to
clarify
that
to
announce
label,
at
least
from
like
rusbot's
perspective,
is
for
this
meeting
to
be
announced.
But
we
can
also.
A
So
to
announce
in
the
labels
for
intended
to
be
the
equivalent
of
nominated
them.
A
Interesting,
I
think
that
it
might
make
sense
for
us
to
rename
that
then,
since
nominated
usually
has
more
of
the
implication
of
let's
discuss
that
in
a
meeting
and
announce
sounds
more
like.
Let's
talk
about
this
publicly,
but
we
should
figure
that
out
regardless.
A
If
you
think
that
this
would
benefit
from
a
public
discussion
and
blog
post
felix,
then
by
all
means
we
have
done
that
for
several
other
rf,
several
other
mcps.
If
you
don't
think,
there's
value
in
that-
and
it
just
needs
to
be
implemented
and
then
discussed
then
either
way
as
the
liaison
by
all
means.
Okay,.
A
Next
up
we
have
length
team
77,
which
is
the
for
dref
patterns.
This
was
discussed
fairly
extensively
on
internals
and
on
zulip
and
then
brought
to
an
mcp
five
days
ago.
So
this
is
the
first
meeting
for
it.
The
proposal
on
the
table
here
is
a
generalized
mechanism
to
match,
through
draft
implementations,
so
box
matching
boxes
matching
strings,
as
stir
matching
backs
as
slices
and
so
on.
A
So
the
proposal
here.
I
think
this
makes
a
huge
amount
of
sense.
I
there
are
a
couple
of
issues
that
need
to
be
dealt
with
on
this
primarily
how
few
times
can
draft
be
called,
and
is
it
going
to
be
possible
to
have
exhaustiveness
checking,
given
the
possibility
of
non-item-potent
implementations
of
draft.
A
A
Some
of
the
issues
I
think
just
need
addressing
by
the
individual
people
working
on
this
to
try
to
figure
out
the
right
solutions
and
proposals.
I
think
one
item
that
could
potentially
use
language
team
feedback
early
on
is
our
general
temperature
as
far
as
syntax
or
non-syntax,
there
was
discussion
about.
Do
we
want
to
label
this
syntax
explicitly
or
do
we
want
to
allow
this
implicitly.
A
Uncharacteristically,
because
I
tend
to
be
the
person
who
would
like
more
explicit
syntax
in
patterns,
I
actually
don't
feel
that
the
current
proposal
needs
additional
syntax,
primarily
because
it's
focused
on
literals
and
I
don't
think,
there's
a
problem
with
literal
matching.
Without
us,
an
extra
sigil,
the
my
only
concern
has
been
if
you're
matching
a
variable
with
an
extra
without
an
x
residual
and
its
type
is
different
through
a
draft.
C
B
A
Okay,
I
will
write
a
quick
summary
to
the
issue,
then
saying
that
there
was
general
support
and
were
looking
for
someone
to
liaise
for
this.
A
I
think
that
that
would
make
sense,
but
I
suspect
that
we
should
probably
well.
On
the
one
hand,
it
would
be
nice
to
have
a
liaison
to
help
coordinate
that
and
make
sure
that
it's
prepared
for
a
meeting.
On
the
other
hand,
preparing
that
and
bringing
it
to
a
design
meeting
may
potentially
help
to
obtain
a
liaison.
A
A
A
Not
necessarily
it
depends
on
how
much
additional
stuff
needs
doing,
but
I
will
mention
that
you
will
chat
with
them
about
coming
to
a
design
meeting
cool.
A
A
A
A
Then
back
under
active
projects,
I
think
constable
precedes
a
pace.
I
don't
believe
there
are
any
active
updates
on
this
one.
A
C
A
A
C
A
Yeah
that
one
definitely
deserves
a
dedicated
blog
post,
above
and
beyond
the
release,
notes.
A
D
With
my
like
release
hat
on,
if
lane
feels
that
that
is
the
actual,
like
the
correct
thing
to
do,
I
don't
know
that
release
is
like
the
right
people
to
write
that
blog
post.
A
No,
I
don't
think
we
would
expect
that
from
the
release
team.
That
would
be
more
to
ask
than
just
simple
release
notes.
I
think
someone
who
is
an
expert
on
the
feature
who's
been
shepherding.
It
needs
to
write
up
an
explanation
of
here's.
The
subset
you
can
use
that
kind
of
thing
here
is
what
is
available,
so
I
think
the
right
way
to
handle
that
would
be
to
discuss
it
via
the
tracking
issue.
A
So
I'm
trying
to
dig
up
that
tracking
issue
there.
It
is
it's
in
the
the
summary
mencap's
generics
tracking
issue.
A
A
Okay,
I
will
write
a
quick
note
to
that
issue,
suggesting
that
a
announcement
blog
post
having
a
draft
announcement
blog
post
would
be
helpful.
B
A
We
should
given
that
boats
will
not
be
available
for
some
time.
Then
I
think
we
do
need
to
have
another
liaison
for
this,
at
least
for
the
short
term
of
getting
the
blog
post
up
and
similar
the
longer.
D
D
A
No,
of
course,
I
think
we
need
to
prepare
that
blog
post
and
then
it
should
go
up
right
around
the
time
that
that
release
is
being
prepared.
A
A
Then
we
already
covered
the
trailing
semicolons
and
expression
macro
bodies
earlier
safe
transmute
is
continuing
to
work
through
the
next
round
of
iteration.
There's
been
some
ongoing
discussion
about
design
elements.
I
think
that
most
of
the
issues
have
been
resolved,
but
I
think
we
should
wait
until
that
one
is
ready
to
come
to
another
design
meeting
with
the
new
approach.
A
Moving
on
to
the
next
column,
rfc
2229
is
planned
for
tomorrow's
design
meeting.
I
believe-
and
there
is
a
document
that
nico
posted
in
zulip
under
design
meeting
20210119,
actually,
presumably
that
should
be
20
2101
20..
Let's
fix
that.
A
Yes,
there's
a
zulu
stream
there
discus
with
a
design
document.
A
A
A
No
updates
on
inline
assembly
and
then
raw
ref.
I
believe
that
there
was
some
discussion
in
the
last
couple
of
weeks
about
trying
to
figure
out
if
the
names
are
sufficiently
finalized,
that
we
can
start
recommending
this
as
an
alternative
to
existing
things.
People
currently
do
other
than
naming.
I
don't
think
there
was
any
update
this
week
and
I
think
that's
it
for
the
board,
unless
anybody
has
anything
to
add.
B
A
I
think
there
was
some
brief
dialogue
on
zulip,
but
very
brief,
like
the
sum
total
of
it
was
some
discussion
about
wanting
to
recommend
these,
as,
for
example,
in
suggestions
and
warnings
or
similar
when
trying
to
take
references
to
things
that
kind
of
thing
and
then
a
brief
mention
from
ralph
of
we
should
get
the
naming
finalized,
and
that
was
it.
A
So
this
was
not
an
extensive
discussion,
just
an
observation
that
we
should
either
figure
out
that
we're
comfortable,
recommending
these
using
their
current
names
and
or
start
figuring
out
what
they
should
be
called
long
term.
C
A
A
A
A
This
is
saying
deny
after
forbid
breaks
something
except
that
81087,
the
pr
that
was
proposing
to
fix
this
was
not
about
deny
it
was
about
having
an
allow
in
the
derived.
I
believe.
D
Well,
so
the
the
pr
81087-
it's
not
like
specific
to
allow
it's
any
any
lowering
of
the
forbid
level
within
derived
macro
right
that
could
be
deny
that
could
be
allow.
It
could
be
worn.
A
Right,
so
that
makes
sense,
I'm
more
wondering
the
oh.
I
see
I
see
so.
The
error
message
that's
mentioned
in
80988
is
not
actually
related
to
the
code
sample
here.
This
is
actually
summarizing.
The
other
issue
with
using
derive,
in
which
case
that
was
due
to
an
allow
separate
from
that
the
forbid
deny,
is
a
an
issue
as
well.
Okay,
that
makes
sense.
A
A
The
discussion
in
the
pr
and
the
response
that
I
made
was
the
comment
that,
like
this,
is
kind
of
what
forbid
does
allow,
after
forbid,
seems
like
it
would
make
for
bid
meaningless,
but
that's
something
we
may
want
to
discuss
further
separate
from
that
deny
after
forbid
seems
redundant
but
harmless.
So
if
that's
something
that
it
sounds
like
that
breaks
well
things.
C
A
Right
so
question
on
that
previously
in
149
or
before
this
was
I'm
assuming
this
wasn't
a
workaround
for
forbid.
You
couldn't
forbid,
then
deny
then
allow
to
ease
it
up
to
allow
without
a
warning
or
error.
D
Well
so
behavior
before
150,
so
in
149
and
before
forbid
and
deny
like
on
the
same
level,
you
would
basically
be
able
to
edit.
So
the
forbid
would
not
really
take
effect
until
the
next
level.
It
would
sort
of
declare
itself.
D
On
the
same
level,
which
might
be
in
in
a
different
file
in
a
different
module
because
of
inner
and
outer
attributes,
you
would
be
able
to
sort
of
edit
the
things
you
said
and
the
behavior
in
150
is
that
forbid
immediately
takes
effect,
and
that
makes
for
bid
warnings,
for
example,
really
strong,
because
previously
it
sort
of
only
affected
warnings.
But
now
it
affects
everything.
A
D
Presumably
yeah
so
the
behavior,
so
the
interesting
thing
is
forbid
previously,
when
you
said
forbid
warnings.
My
understanding,
when
I
looked
at
the
code
is
that
it
actually
didn't
actually
take
effect
like
if,
if
you
wanted
to
after
forbid
warnings
on
a
completely
different
level,
you
could
still
allow
the
lint.
As
long
as
you
didn't
allow
warnings,
you
could
allow
any
of
the
sublint.
D
Within
the
group,
and
so.
A
A
I
see
so
that
sounds
like
there's
three
behavior
changes
here
then
the
or
rather
one
that
is
involving
the
use
of
warnings,
specifically
one
regarding
the
use
of
deny
and
one
regarding
the
use
of
allow.
D
I
don't
think
there's
any
change
to
deny
specifically
there's
there's
two
changes
since
150
or
since
149.
The
first
one
is
that
individual
lints
are
now
like
forbidden.
If
the
group
is
forbidden
as
well
and
right.
That
is
actually
that's
the
only
change,
but
there
are
various
effects
of
that.
A
Oh,
I
thought
that
there
was
also
a
change
to
make
for
bid
take
effect
immediately
rather
than
at
a
lower
level.
That
was
in
a
previous
release
or
not
at
all.
A
A
This
is
lintz
and
we
are
allowed
to
be
stricter
about
lengths
in
ways
that
cause
people
who
use
deny
or
forbid
to
get
compile
errors
that,
although
I
think
we
are
on
a
borderline
case
there,
because
normally
a
reason
we
allow.
That
is
because
of
cap
lengths.
D
B
D
D
A
A
A
This
is
not
uncommon
yeah,
so
the
case
that
I
was
making
a
couple
of
days
ago
in
8108.7
was
that
this
was
always
what
people
who
said
forbid
were
looking
for,
insofar
as
it
was
supposed.
I
mean,
there's
not
a
lot
of
point
in
doing
forbid
in
to
break
to
make
sure
that
your
own
code
can't
do
allow
it's
kind
of
belt
and
breaks
is
safety,
but
presumably
you're
maintaining
that
project.
So
you
can
also
just
not
allow
something.
A
I
think
I
made
it's
helpful
and
it's
a
good
flag
up
at
the
top
that
you
don't
have
to
dig
further
into
the
code
if
you're
reading
it,
but
it
seems
like
a
substantial
value
here
is:
don't
allow
the
introduction
of
allows
by
other
things,
including
things
I
might
not
see
buried
in
a
macro.
If
you
say.
D
I'm
pretty
sure
that
the
unsafe
actually
like,
I
think,
some
of
the
macros
instead
use
unsafe
internally,
and
they
have
like
some
sort
of
hygiene
for
not
like
that,
like
you
can
put
a
thing
on
a
macro
that
says
this
is
hiding
unsafe
code,
but
forbid
it
shouldn't
apply
to
it
or
deny
or
whatever.
A
C
D
A
So
presumably
you
would
have
had
this
issue
before
if
you
used
allow
within
a
nested
scope,
just
not
at
the
top
level
right.
This
is
related
to.
We
now
make
forbid,
take
effect
immediately.
So
if
you
were
already
in
a
nested
scope
like
within
a
function,
then
allow
wouldn't
have
been
allowed
and
derived
even
wouldn't
have
been
allowed.
We
just
almost
never
do
that
inside
an
inner
scope.
A
The
only
issue
is
that
people
writing
for
bid
warnings
might
not
have
gotten
instant
feedback
that
that's
probably
a
bad
idea
until
now.
But
yes,
given
that
cap
lintz
is
a
thing
then
hopefully
people
will
notice
and
address
that
so
yeah.
I'm
less
concerned
about
the
forbid
warnings
problem
and
more
concerned
about
if
somebody
forbid
a
specific
thing
and
then
now
finds
they
can't
use
derive.
D
It
I
might,
I
think
my
current
position
is
that
breaking
people
who
say
forbid
and
then
derive
a
macro
that
allows
that
is
perhaps
suboptimal
in
the
sense
that,
like
that
macro
is
maybe
not
the
best
macro
like
as
a
macro
author.
I
would
want
to
avoid
using
allow
on
things
that
people
might
want
to
forbid.
A
Yeah,
I
would
agree
with
this
as
well.
Yes,
I
do
think
if
we're
gonna
fix
anything,
the
ideal
fix
would
be
to
make
derive
no
longer
need
to
allow
unused
qualifications
and
instead,
just
not
have
an
unused
qualification.
If
that's
at
all
possible.
D
Well,
there's
there's
two
parts:
there's
two
possibilities
right:
you
can.
You
can
make
unused
qualifications
as
a
rust
c
lint
like
we
have
the
ability
to
say
this
lint
doesn't
take
effect
in
macro
expansion,
or
at
least
I'm
pretty
sure
we
do,
which
means
that
we
can
potentially
fix
it.
That
way
too
and
just
say,
like
there's
no
point
to
allowing
it
because
it
just
doesn't
get
emitted
inside
macros,
which
is
something
many
lints
do.
A
That's
actually
perfectly
fair,
unlike
making
ineffectual
in
macros,
which
I
don't
think
is
a
good
idea
allowing
specific
links
in
macros
in
general
on
the
basis
that
they
commonly
happen.
When
you
write
the
kind
of
code
that
appears
in
a
macro
we've
done
that
before
and
that
doesn't
seem
unreasonable
for
unused
qualifications
or
in
general
unused.
Something
in
a
macro
doesn't
seem
unreasonable.
D
Yeah,
I
I've
had
mixed
feelings
before
in
some
sense,
it's
useful,
like
I
would
like
for
us
to
provide
an
opt-in
of
some
kind,
because
it's
as
a
sort
of
when
you
write
the
macro,
you
often
want
to
know.
If
you
are,
you
know
generating
useless
parentheses
or
whatever,
but
as
a
sort
of
macro
user.
I
agree
that
the
it
is
not
helpful
to
me
to
have
to
know
that
this
macro
has
unused
qualifications.
C
B
B
D
A
Okay,
well
in
the
interest
of
trying
to
put
a
bound
on
this
discussion,
and
we
can
always
continue
it
later
via
the
zoo,
either
zulup
or
github.
Would
it
be
accurate
to
say
the
general
consensus?
Is
we
don't
want
to
revert
the
new
behavior,
but
we
might
be
open
to
some
changes
in
other
aspects
of
lint
handling
to
reduce
this
breakage
for
things
like
derive
either
fixing
derive
if
that's
an
option
or
having
specific
lengths,
narrowly
targeted
to
not
apply
within
macros.
A
That's
a
fair
point.
Yes,
that's
probably.
C
Right
but
but.
A
C
D
I
I
don't
object.
I
would
like
to
see
someone,
I
guess
maybe
josh
you
can
do
this
write
it
on
the
issue,
and
maybe
I
don't
know
if
ftp
is
the
right
thing,
but
it
feels
like
there
are
multiple
people
online,
not
in
this
meeting.
Yes,.
A
I
agree
that
was
actually
going
to
be.
My
next
suggestion
was
scott,
since
you
just
finished
summarizing
that
very
well,
I
wondered
if
you
would
be
up
for
writing
that
on.
I
think
80988
is
the
issue
that
should
be
on
and
then
a.
I
will
write
a
quick
note.
A
A
I
think
we
should
close
and
just
say
no,
don't
do
that
the
77713
or
in
general,
the
issue
with
derive
that
one
we
should
leave
open
on
the
basis
of
we
may
fix
that
by
fixing
derive
or
by
changing
what
length,
supply
and
macros
so
that
one,
wherever
that's
being
tracked,
should
be
open
to
track.
What
we're
doing
to
address
it.
C
A
C
Fcp
closed
the
regression
for
1.50
item
as
agreed.
Yes,
we
proposed
to
just
do
this
in
1.50
and
if
other
issues
still
exist,
that
are
where
people
consider
other
changes,
that's
fine,
but
for
the
purpose
of
1.50
and
getting
that
shipped,
the
behavior
that
is
implemented
is
the
behavior
that
we
are
proposing
out
of
this
meeting.
We
stick
with
for
1.50.
A
Agreed:
okay,
go
ahead
and
post
that
to
80988,
and
I
will
post
a
note
to
81087
mentioning
that.
There's
some
discussion
about
this
on
80988
and
that
we're
also
open
to
other
ways
of
addressing
derived
specifically.
A
8108,
no,
I
think
that
for
8
108.7
the
the
specific
proposal,
pr
is
one
that
I
don't
think
that
we
should
accept,
although
I
would.
D
B
A
I
will
finish
typing
that
note
up
after
the
meeting,
so
that
we
can
go
on
to
other
items,
one
that,
because
we
had
a
couple
of
large
items
we
may
or
may
not
have
bandwidth
to
go
through
all
the
nominated
prs
and
issues,
but
one
that
is
substantially
overdue.
I
think
at
this
point
is
seven
nine,
oh
seven,
eight!
A
A
It
might
actually
be
worth
checking
if
it
still
triggers
the
same
warnings
which
would
give
us
yet
another
reason
to
potentially
merge
it
if
it
does
not.
But
that
aside,
all
of
the
open
issues
in
this
have
been
addressed.
I
closed
the
perf
related
blocker
on
the
basis
of
our
previous
discussions
that
that's
the
compiler
team's
business
and
not
ours
to
address,
and
apart
from
that,
we
are
just
waiting
on
check
boxes
for
figuring
out
whether
we
merge
this.
C
A
So
I
believe
that
several
of
the
things
that
he
was
mentioning
are
actually
summaries
of
specific
things
we
discussed
in
the
meeting,
and
I
think
the
main
blocker
was
addressed
already,
specifically,
that
the
use
of
derive
as
a
magically
evaluate
configuration
really
should
deserve
more
discussion
than
just
with.
This
was
accidental
and
it
seems
useful
and
based
on
that
petrochenkov
removed
the
ability
to
do,
derive
and
other
attributes
in
an
order
that
would
allow
other
attributes
to
see
that
derive,
expands,
cfgs,
so
yeah.
A
This
no
longer
has
a
visible
effect
on
config
evaluation
anymore,
which
means
I
think,
that
it
should
be
substantially
less
controversial
and
then
later
we
can
make
a
decision
about
if
we
want
to
allow
it
to
expand
config,
visibly
or
if
we
want
to
create
a
separate
thing
for
that
or
any
number
of
things
but
yeah.
I
think
that
that
all
has
been
addressed,
and
we
don't
have
enough
people
in
this
meeting
to
sign
off.
A
A
That,
okay
moving
on
it,
appears
that
ore
patterns
is
still
nominated.
We
should
we
discussed
this
briefly
last
time,
and
I
think
the
issue
was
that
we
want
to
make
get
this
on
its
way
to
stabilization.
A
So,
given
that,
I
think
we
are
reasonably
prepared
for
an
fcp
to
stabilize
ore
patterns,
that
would
be
seven
nine,
two
seven
eight,
I'm
gonna
do
a
quick
check
to
see
if
we
have
a
let's
see
yeah
that
looks
like
it's
on
track,
so
any
objections
for
doing
an
fcp
to
merge
seven.
D
A
Two
seven
go
on
so.
A
A
A
Okay,
that's
posted.
A
B
A
B
A
Sounds
good
in
that
case,
I
think
that
we
want
to
skip
both
this
issue
and
the
next
one
until
we
have
that
code
prepared.
I.
C
Question
on
this
one,
it
says
to
deny
in
the
header
and
into
errors
in
the
op.
Is
this
making
them
errors
or
making
them
deny
by
default?.
A
E
A
Deny
I
was
just
sloppy
in
my
wording
here
perfectly
fine.
I
I
use
the
same
thing:
make
them
errors
when
we
mean
like
make
this
deny
by
default.
We
honestly
there
is
very
good
argument.
There's
it's
unusual
going
to
be
unusual
for
us
to
turn
something
like
this
into
a
hard
error.
Unless
we
have
some
long-term
plan
to
reclaim
syntax
or
similar.
A
A
A
Right,
I
don't
think
we
need
to
step
up.
Warn
then
deny
then
hard
error
over
three
editions.
I
think
that
we
shouldn't
go
directly
from
allow
to
hard
error
in
an
addition,
under
almost
any
circumstances,
if
we
can
help
it,
but
going
going
deny
then
hard
error
seems
reasonable
going
warn
then
hard
error
seems
plausible.
Depending
on
how
strenuous
the
warning
text
is.
If
it
goes
out
of
its
way
to
say
this
won't
be
allowed
in
the
future,
then
we
might
be
able
to.
A
C
A
A
So
I
would,
I
would
suggest
that
we
decide
on
these
independently
and
I
would
propose
that
we
do
two
separate
fcps
one
fcp
on
80165
for
the
proposal
to
promote
all
of
these.
To
deny
now
again
the
open
question
is
we
still
need
to
review
several
of
these?
It
sounds
like
several
of
these
are
uncontroversial.
A
C
I
think
I
liked
what
you
said
earlier
of:
let's
split
these
up,
if
it
should
be
a
relatively
straightforward
chain,
pr
to
change
the
a
single
one
of
these
lengths
from
to
be
denied
by
default
in
2021
right.
C
C
Issue
is
still
valuable
and
we'll
check
them
off
here
with
the
prs
as
they
go
in
or
whatever,
but
that
if
we
split
them
up
into
separate
ones,
that'll
probably
help
the
simple
ones
go
quickly
and
give
a
more
specific
place
for
discussing
harder
things.
Like
I
remember,
a
lighted
lifetimes
in
paths.
People
have
some
objections
to
in
some
of
the
positions
for
whether
the
tick
underscores
are
valuable
or
not,
or
a
bunch
of
things
like
that.
A
That
makes
sense,
and
I
think,
that's
strictly
better
than
what
I
was
originally
going
to
propose,
which
was
using
lan
team
issue
65
to
do
a
fcp
on.
Do
we
want
to
make
bear
trade
objects,
a
deny,
or
rather
a
hard
error?
If
we're
going
to
do
that,
we
could
just
have
that
be
a
separate
item
for
discussion
along
with
the
rest
and
just
decide.
Do
we
want
to
make
this
a
hard
error
or
a
deny.
C
Yeah,
since
we
have
mario.
E
No,
that
sounds
perfect.
I
was
just
fighting
this
issue
to
make
sure
we
don't
lose
track
of
it,
so
I
just
copied.
Basically
I
appreciate
it
you
need
to
discuss
in
here,
but
I
think
that
the
discussion
going
on
for
each
of
them,
so
we
should
probably
split
it.
Yeah.
A
I
think
for
all
of
them
other
than
bear
trait
objects.
It
probably
makes
sense
to
have
this
discussion
on
a
pr
that
is
making
them
deny
by
default,
and
then
we
can
fcp
merge
those
for
bear
trait
objects.
It
sounds
like
we'll
need
to
discuss
whether
we
want
deny
by
default
or
hard
error,
so
we
may
want
to
have
that
discussion
on
a
dedicated
issue
rather
than
a
having
somebody
prepare
a
pr
that
may
turn
out
to
not
be
the
one
we
want.
E
C
C
I'll
add
for
bear
trade
objects
that
if,
if
we
accepted
a
pr
to
make
it
deny
by
default,
we
could
just
say
yes
we're
moving
forward
on
that
and
if
it
then
also
gets
a
later
pdr
to
become
error
by
default.
That
would
be
okay,.
A
You
said
that
you're
currently
filing
an
issue
to
keep
track
of
this
and
make
sure
this
doesn't
get
lost.
Where
is
that
issue
being
filed.
E
No,
I
was
talking
that
this
was
the
issue
for
the
errors.
There
is
no,
there
is
a
project
board
for
all
of
the
2021
edition
things.
Instead
of
a
tracking
issue.