►
From YouTube: 2021 02 23 Lang Team Triage
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).
B
B
A
Okay,
there
are
no
action
items.
I
went
through
them
already,
yay
team,
except
maybe
felix,
but
I
think
you
did
leave
some
comments
on
the
tritrate
version.
2
rfc,
didn't
you.
D
A
Off
you
get
credit,
so
draft
patterns
we
the
team.
Last
time
we
requested
that
people
should
they
should
update
the
charter
to
scope
it
to
standard
library
types
they
did
so.
I
feel
pretty
okay
about
pursuing
this
now.
Is
it
scott,
as
liaison?
A
E
You
can
say
no,
no
I'd
like
I'd
like
to
see
this
it'd
be
a
good
thing
to
have
so
we'll
see
what
happens
all
right.
A
Then
there's
an
action
item
here
which
is
fcp,
merge
I'll,
do
it
since
I've
been
commenting
until
now,
all
right,
add
const,
ub
rfc
number,
three
zero
one.
Six,
sorry.
C
Quick
point
of
order,
as
as
note
taker
am
I
also
responsible
for.
A
Yeah,
sorry,
I'm
just
so
accustomed,
I
will
not
type
unless
necessary.
You
don't
have
to
add
them
to
the
action
item
list.
That's
mark's
job,
but
you
have
to
add
them
to
this
doc.
A
You
because
we
believe
in
whatever
the
opposite
of
dry
is
redundancy.
So,
okay,
what
do
we
have
here?
Add
constitue
brfc.
So
last
time
this
was
on
the
list,
but
I
skipped
it
because
I
didn't
know
why
and
ollie
left.
The
comment
seems
like
the
answer.
Is
it's
at
a
steady
state
and
there's
some
implementation
work
that
has
been.
A
E
C
A
E
A
A
A
Sorry,
I
don't
think,
there's
a
totally
clear
answer
yet
I
didn't
actually
read
the
updates
that
ryan
posted,
but
one
thing
that
also
came
up
on
zulip
that
I
just
saw
was
that
there
are
some
other
problems
like
if
you
have
a
macro
that
recursively
uses
itself,
even
if
it
doesn't
rely
on
shadowing
and
you
use
that
macro
from
another
crate,
then
lacking
hygienic
paths
means
that
the
macro
will
can't
invoke
itself.
Does
that
make
sense
like
I'm?
A
F
So
the
so
we
tried
to
differentiate
between
recursive
versus
private
macros,
recursive,
macros
being
ones
that
call
themselves,
and
if
you
have
a
macro
that
calls
itself
if
it's,
if
it's
top
level
invocation,
is
happening
through
some
scoped
path,
like
let's
say
it's
defined
in
module
m
inside
of
another
module
in.
F
If
you
try
to
invoke
that
macro,
it
will
try
and
call
itself
just
with
with
no
path
attached
to
it.
So
inside
of
itself,
it
would
just
call
you
know
my
macro
or
whatever,
and
then
when
it
gets
expanded,
it
gets
expanded
just
to
my
macro
and
not
to
the
fully
qualified
path
to
where
it
lives,
and
so
we
don't
know
which
macro
you're
actually
calling.
F
And
so
one
possible
solution
to
that
would
be
to
introduce
a
new
kind
of
macro.
Specific
keyword
similar
to
dollar
sign
crate,
like
dollar,
sign
self,
which
would
refer
to
the
the
module
where
the
macro
is
being
defined
in.
But
that
also
has
several
problems
like.
If
the
macro
is
re-exported,
then
it's
still
not
available
through
its
fully
qualified
path.
It's
available
through
some
other
path,
so
there's
a
whole
bunch
of
problems.
There.
A
I
have
to
say
this
makes
me
somewhat
like
I
don't
know
like
less
keen
on
doing
this.
Maybe
nick
cameron
was
right
in
his
comment
that
why
bother-
let's
just
make
macro
work.
It's
not
that
this
particular
thing
is
not
bad.
It's
just
it's
just
that
we
keep
coming
up
with
new
little
things
and
I'm
worried.
B
I
I
guess
I
it
seems
like
we
had
an
alternative
strategy
to
trying
to
mitigate
them
directly
to
just
say:
yeah,
we're
going
to
migrate
all
macros
to
have
an
attribute
on
them.
That
says
it's
a
legacy
macro
and
then
you
know
new
macros
get
written
and
they
get
off
into
and
they
avoid
all
these
problems
because
they
just
don't
encounter
them
from
the
first
place.
G
Well,
there
is
one
concern
there,
though,
even
if
we
do
that,
we
need
to
specify
what
we
expect
people
to
do
as
a
replacement
for
repeatedly
define
the
same
macro
and
use
it,
and
if
we
have
an
expected
replacement,
that's
fine,
but
the
expected
replacement
can't
be
tag.
Your
brand
new
macro
as
a
legacy
macro.
F
Yeah,
exactly
there's
no
clear
path
forward
to
how
you
would
actually
make
this
work
in
the
in
the
new
system,
and
that's
not
even
the
only
one.
There's
also
the
fact
that
that
macros
can't
shadow-
and
so
you,
if
you
define
a
macro
multiple
times
within
another
macro.
Previously,
that's
fine.
It
would
just
shadow
the
previous
definition,
but
now
you
get
a
namespace
clash
and
there's
really
no
way
to
avoid
that.
B
A
Shadowing
feels
pretty
obscure
to
me.
I
don't
I
could
live
with
that.
I
feel
like
there's
got
to
be
some
ways
to
manage.
It
never
even
occurred
to
me
as
something
to
do
in
the
first
place.
Recursion
is
like
I
don't
know.
I
know
if
it's
not
trivial,
it's
recursive,
because
that's
the
only
way
you
parse
in
a
macro,
as
far
as
I
can
tell
so,
I
feel
like
we
want
at
least
a
solution
to
that
dollar
self
might
be
a.
E
Tolerable
one,
we
already
say
that
dollar
self
is
the
breaking
change
that
we
couldn't
do,
because
we
wanted.
B
C
A
E
A
I
remember
a
previous
use
of
tell
herself.
That
was
something
I
was
wondering.
What
other
feels
like
something?
That's
spoken
for,
if
dollar
self,
ignoring
that
problem
ryan,
did
you
consider
that
maybe
it
expands
not
to
where
the
macro
was
defined
but
to
the
path
that
was
used
to
name
the
macro,
because
that's
yeah
the
right
thing.
F
A
F
F
The
the
alternative
would
be
that
dollar
sell
for
whatever
we
we
call.
This
thing
would
expand
basically
to
the
path
that
the
top
level
macro
was
called
through.
So
if
the
top
level
macro
is
called
through
module,
1
colon
colon
module,
2
colon
colon,
my
macro,
then
dollar
self
would
expand
to
module
one
colon
colon.
A
G
Well,
one
one
notable
thing
here:
we
don't
necessarily
have
to
define
this
in
a
way
that
it
is
expressible
in
surface
syntax,
because
a
macro
could
output,
something
that
parses
as
rust.
But
it's
directly
interacting
with
the
parser,
which
is
to
say
we
could
have
a
token
that
expands
to
call
myself
and
I
don't
care
what
path.
I
am
call
me,
you
know
what
me
is
because
you're
expanding
me
right
now.
D
I
I
have
a
question:
how
much
of
the
design
work
we're
doing
right
now
or
would
be
doing
the
future
is
going
to
be
applicable
to
the
you
know
what
nick
wants,
in
terms
of
the
new
macro
style
thing
versus
like
no?
This
is
just
for
macro
rules
and
has
no
purpose
in
the
new
world
and
thus
is,
from
my
perspective,
potentially
wasted
effort.
G
A
If
we
had,
if
we
had
path
hygiene
as
has
been
proposed,
then
when
you
write
foo
you're,
resolving
it
relative
to
the
macro
definition,
not
the
macro
use,
so
you
can
naturally
call
yourself
very
easily
and
it
doesn't
matter
it's
not
something
you
could
necessarily
type
like.
It
bypasses
the
privacy
system,
which
is
another
interesting
facet
of
hygiene,
there's
kind
of
two
ways
to
do.
Privacy
then,
but,
but
that's
why
I
would
agree
with
taylor
that
this
is
wasted.
A
Effort,
I
don't
know
I.
On
the
one
hand,
I
really
like
I've
already
kind
of
in
my
head
decided.
We
have
this
feature
and
I
want
it
and
I've
been
wanting
to
use
it
like
in
the
standard
library
to
put
random
little
macros
in
places,
sub
modules
and
things
like
that,
and
we
can
do
it.
I
guess
in
the
standard
library
with
pub
macro,
but
on
the
other
hand,
I'm
kind
of
like
this
is
a
lot
of
work,
that
this
is
no
one's
asking
for
sort
of,
but.
C
A
A
B
A
Yeah,
so
one
argument
is
to
go
with
petroshankop's
original
proposal
right
and
make
it
like.
The
legacy
forum
is
no
public,
so
all
code
keeps
working,
but
then
you
can
write
public
there's
a
better
version
of
macro
export,
essentially.
G
And
you
can
do
pub
self
if
you
really
want
the
that
behavior.
B
I
I
would
not
also
be
opposed
to
making
it
just
an
attribute.
Also,
if
we
wanted
to
mitigate
the
like
pop
self
is
not
removal
of
pub
effect.
A
G
A
I
would
say
I
don't
mind
the
attribute,
but
I'm
not
crazy
about
I'm,
not
crazy
about
it.
As
like
a
permanent,
I
don't
know
solution.
It
feels
weird
to
me,
but
the
other
thing
I
would
say
is:
if
we
don't
solve
dollar
self
now
we
can
solve
it
later.
G
So
previously
we
talked
about
that
as
a
migration
mechanism.
Of
this
way,
we
don't
break
anyone
and
require
any
kind
of
transition,
but
I
think
it
may
be
more
practical
as
a
here's,
how
we
let
you
keep
doing
everything
you
could
do
before
without
us
having
to
define
a
replacement
for
everything.
A
A
There's
I'm
going
to
call
it
create
local,
but
that's
where
you
I
forget:
what
is
it
macro
use
a
module
essentially
and
then
there's
sort
of
module
local
right,
and
I
think
we
reasonably
cleanly
solve
this
problem
with
the
pub
opt-in.
B
A
Is
like
sort
of
solved
it's
a
little
awkward,
because
you
have
to
know
the
way
to
name
yourself,
but
if,
but
you
can
do
it,
you
have
to
make
the
whole
path
like
have
to
name
yourself
via
crate,
local,
absolute
yeah,
crate
path
or
whatever
right.
Essentially
the
same
way.
You
would,
if
you
were
macro
exporting
and
this
one
we're
saying
not
so
bad
today.
That's
kind
of
the
argument
right.
A
I
just
mean
that
if
we
just
do
the
patriarchal's
original
proposal,
which
I'm
calling
puboptin,
meaning
that
the
new
behavior
is
opt-in
via
the
pub
keyword,
I
it
doesn't
seem
to
me
such
a
problem
to
you.
You
have
to
name
yourself
via
an
absolute
path
that
is
publicly
nameable,
but
that
path
is
kind
of
guaranteed
to
exist,
because
otherwise
they
couldn't
invoke.
You
right.
A
A
A
Yeah,
that's
the
problem.
I
guess
that
I
think
the
problem
taylor
is
raising
is
something
like
crate.
A
says,
like
I
put
my
pub
macro
rules
and
we
should
probably
move
on
at
some
point,
but
this
is
kind
of
productive,
but
the
point
is
I
I
name
it
in,
like
dollar,
crate,
foo
or
something
and
then
crate
b
tries
to
pub
use
crate.
A
foo
m
and
crate
c
invokes
it,
and
now
it's
not
gonna
work.
Probably
I
don't
know,
don't
quite
know.
A
What's
gonna
happen,
I'm
actually
not
exactly
sure
what
happens
with
macro
re-exporting.
A
Yeah
I
mean
I'm
definitely
not
super
keen
on
a
system
where
it's
like
they
work
just
like
regular
items.
As
long
as
you
don't
do
a
lot
of
the
things
you
can
do
with
regular
items,
at
which
point
they
start
to
work
in
odd
ways,
in
which
case
I
kind
of
rather
just
keep
our
own
wacky
system.
We
have
now.
B
I
guess,
as
as
one
potential
sort
of
smaller
step,
we
could
do,
and
I
don't
know
if
I
don't
think
so
does
this
today,
but
we
could
say
that
you
know
we
want
some
solution
that
allows
non-uh,
crate
global
macro
export
and
in
order
to
facilitate
that,
like
we're,
okay
with
you
know,
stood
having
macros
that
are
local
and
potentially
those
work
because
of
stood
magic
and
unstable
features
or
whatever.
But
you
know
we
don't
actually
stabilize
anything
here.
A
F
F
A
Okay,
let's
move
on
yeah,
so
repper
c
is
unsound
on
msvc
targets.
Eight
one,
nine,
six,
six
josh
posted
a
comment.
Last
time
we
discussed
this.
We
wanted
rep
c
to
match
the
c
compiler.
I
skimmed
the
follow-up
comments.
They
seemed
like
extensions,
but
not
contradictions
like
it
would
be
useful
to
have
a
warning
about.
A
Because
they're
outside
of
the
c
standard-
and
there
might
be
some
uses
for
rapper
stable,
but
I
think
our
job
is
done
here.
G
For
the
most
part,
I
there
has
been
some
ongoing
discussion
on
both
the
issues
and
zulip
to
follow
up,
and
there
is
one
specific
point
that
I
think
the
lang
team
would
need
to
chime
in
on
concretely,
even
if
we
say
that
zero
size
types
in
repro
c
should
be
laid
out
like
the
native
c
compiler
such
that
it
might
not
be
zero
sized
effect
on
the
layout.
G
There
is
still
the
case
of
the
specific
zero
size
types
of
phantom
data
and
phantom
pinned,
which
people
use
those
expecting
that
they
truly
don't
affect
the
layout
at
all,
and
it
is
perfectly
reasonable
to
use
those
in
a
represent
structure
that
you
are
also
attempting
to
express,
for
example,
lifetime
issues
with,
given
that
we
might,
if
we're
going
to
treat
constructed,
zero-sized
types
like
an
empty
enum,
for
example,
as
a
or
one
item
enum,
rather
as
a
a
thing
that
potentially
hap
doesn't
take
up
any
space
but
takes
up
space
due
to
alignment.
G
C
Put
a
non-wrapper
c
zero
size
type
in
a
represent
right,
and
I
think
the
case
there
is
that
it
should
at
least
my
opinion
would
be
that
it
should
still
be
zero
size.
It
should
have
no
effect
on
layout,
but
if
you
have
a
zero
member
represent
in
c
type,
then
it
should
potentially
affect
layout
as
per
the
appropriate.
You
know,
guess
at
what
a
c
compiler
on
the
platform
does.
G
Agreed
no,
if
we
were
gonna
do
that
it
would
be
some
kind
of
tag
on
those
types
that
similar
to
repreventum.
But
no,
I
think
taylor's
point
is
substantially
better.
The
idea
that
represent
types
behave
like
zero
sized
things
do
in
c,
but
that
doesn't
mean
that
things
that
are
zero
sized
in
rust
and
therefore
allowed
should
change
behavior.
G
E
C
E
C
G
A
I
think
you
can
do
it.
It's
just
not
can
be
necessarily
compatible
with
c
in
any
particular
way.
G
A
E
E
G
Yeah
that
discussion
came
up
on
zulip
as
well,
and
I
think
that
just
because
people
are
using
repercy
to
mean
wrapper
in
order,
but
I
don't
actually
care
about
the
layout-
doesn't
necessarily
mean
that
was
the
intended
purpose
and
we
might,
in
the
future,
want
to
add
a
wrapper
in
order
or
refer
stable
or
something
that
will
give
people
what
they're
looking
for
there.
But
at
the
same
time,
that
doesn't
mean
that
ripper
c
is
that
and
that
we
can't
change
it
to
match
c.
A
Yeah,
I
think
we
can
change
it,
but
I
think
we
can't
like
there's
limits
to
how
much
we
can
do.
A
A
E
A
C
E
I
agree
with
that
statement.
Is
it
one
zsts.
A
E
A
B
C
I
would
expect
that
we,
I
don't
actually
know
what
we
do
there,
so
I
I
guess
that
we
would.
We
would
not
guarantee
the
alignment
of
a
zero
zero-sized
array
of
alignment.
A
It's
sort
of
a
convention,
it
means
a
zero
size
type
with
alignment,
one
it's,
but
I
think
it's
in
the
unsafe
code
guidelines
we
bill.
That's.
A
This
was
probably
worth
drilling
into
though
okay
anything
left
to
say
on
that
point,
or
is
it
okay
to
move
on
all
right?
C
G
Thing
I
think,
if
we
were
going
to
make
a
statement
like
that,
we
would
need
a
little
bit
further
clarification
for
what
rep
rust
values
means
because,
for
example,
if
what
you
have
is
a
u32
semicolon,
4,
there's
no
annotation
there
on
either
u32
or
the
slice
type
like
that
or
array
type
like
that.
That
makes
it
wrapper
c,
but
nonetheless
there
is
an
expectation
that
that
will
be
laid
out
as
4
u32s
in
a
row.
G
A
Interestingly,
the
there
is.
A
A
Recall
I
don't
know
anyway,
this
is
obviously
not
official,
but.
A
It
makes
a
much
stronger
statement,
which
is
also
incompatible
with
what
we
said
more
or
less
incompatible
with
what
we
said.
It
kind
of
makes
two
two
core
two
contradictory
statements.
No,
actually
it's
correct.
It's
it
matt
this
this
statement
matches
it
says.
Normally,
it
works
like
this
for
most
platforms,
but
you
have
to
consult
your
actual
specification.
A
A
A
A
Josh,
where
is
this
conversation
happening?
Can
you
just
take
an
action
item
to
summarize
the
stuff.
G
A
Okay,
all
right
moving
on
someone
note
the
action
item
for
dash
so
unsafe
option
in
unsafe
function.
Then,
oh,
nothing
to
say
here
this
is
an
fcp.
We
have
to
wait,
there's
a
pr
79309.
A
It
changes
the
behavior
of
super
inside
modules
that
are
inside
code
blocks
and
it
allows
you
to
name
things
from
the
block.
I
guess
other
items
from
the
block.
This
is
useful
for
rust
duck,
but
petroshankup
doesn't
like
it
and
there's
a
kind
of
question
on
what
to
do.
I
haven't
looked
too
deeply
into
it.
G
I
dug
into
this
and
also
wrote
a
quick
comment
asking
some
questions,
not
least
of
which
this
needs
a
critter
run,
but
general
thoughts.
On
the
one
hand,
this
seems
completely
reasonable
and,
on
the
other
hand,
name
resolution
is
subtle
and
quick
to
anger,
and
how
often
does
this
come
up
and
is
it
worth
it.
G
The
example
up
at
the
top
comment
explains
why
this
is
relevant,
that
we
normally
turn
dot
tests
and
similar
into
a
function
and
wrap
them
in
a
function,
because
you
can
write
items
inside
a
function,
including
mod
declarations
or
anything
else,
and
this
is
one
case
in
which
that
is
not
a
transparent
transformation
that,
if
you
embed
a
module
inside
a
function,
then
any
items
defined
as
siblings.
Of
that
module
are
not
accessible
via
super
the
way
they
would,
if
you
define
them
inside
a
module.
A
G
That
appears
to
be
the
primary
motivating
example.
You
could
obviously
have
this
come
up
inside
of
a
function
elsewhere,
but
people
don't
normally
do
that.
So
I
would
expect
that
ninety
percent
of
the
case
this
practically
affects
his
doc
tests.
E
C
So
the
the
devastating
of
weird
weird
nesting,
though
that
issue
is
sort
of
molded
into
or
or
changed
slightly
into
somewhat
more
of,
like
a
coherence
related
thing,
at
least
from
my
understanding,
given
that
I
think
the
primary
motivation
there
is.
I
like
ide
support
and
laziness
is:
does
that
match
with
with
what
you
had
in
mind.
E
C
Broadly,
like
I
don't
know
how
much
we
want
to
value
this,
given
that
it's
not
particularly
practical
but
like
I
would
ex,
I
would
have
expected
that
this
would
work
like
this
code,
like
if
you
showed
me
this
code,
and
somebody
was
like.
Is
this
valid
rest
code?
I
would
say
I
would
probably
have
said
yes
like
it
doesn't
surprise
me
that
it
doesn't
work
in
the
sense
that,
like
inner,
like
nested
items
are
weird,
but
I
kind
of
like
looking
at
it.
It
looks
like
reasonable
code.
G
A
C
C
A
A
E
A
A
Yes,
no.
A
A
A
A
A
Okay,
allow
qualified
paths
and
struck
construction;
eight,
zero,
zero,
eight,
zero,
scott
or
ryan.
What's
going
on
here,.
E
F
F
G
Yeah,
I
was
under
the
impression
when
we
were
looking
at
this
originally
that
the
thing
that
we
approved
and
went
to
pfcp
on
was
that
we
wanted
to
actually
allow
this
and
not
just
parse.
This
the
example
given,
I
think
a
good
example
summary
is
in
ali
obk's
comment
on
december
18th.
That
shows
an
example
of
doing
this,
as
bar
as
a
colon
colon
associated
and
using
that
as
in
both
patterns
and
expressions,
and
I
think
that
that's
perfectly
reasonable,
and
we
want
to
allow
that.
F
Yes,
it
was
my
understanding
that
that
wasn't
resolved,
although
I
wasn't
here
for
that
meeting.
So
I'm
not
sure.
A
F
Current
currently
with
the
both
the
implementation
of
like
so
there
is
what
is
currently
in
the
language
today
there
is
what
is
in
the
pull
requests,
and
there
is
what
should
be
in
the
language
tomorrow
and
from
what
is
in
the
pull
request.
Right
now
should
not
be
merged,
because
there
is
inconsistency.
F
We
I'm
refreshing
my
memory
as
I
go,
but
basically
for
one
type
of
struct
type.
So,
like
a
tuple
struct,
we
don't
allow.
We
don't
even
we
don't
allow
this,
but
for
struct
trucks
we
do,
and
it
was
my
question
like
I
assume
we
should
be
consistent.
Whatever
is
possible
with
struck
struck
should
be
possible
with
tuple
structs
as
well.
C
I
think
to
to
clarify
what's
happening
here,
if
I
can,
if
I
can
guess
at
it,
when
you
define
a
tuple
struct
you're,
declaring
both
the
type
and
a
function
with
the
same
name
as
the
type
and
and
when
you
create
this,
you
know
associated
type,
alias
you're,
only
aliasing
the
type,
not
the
type
constructor
function.
F
F
Yes,
I
believe
it's
already
in
the
pull
request,
so
I
can
just
hopefully
copy
paste
it.
That's
even.
A
C
A
C
C
C
F
F
D
B
F
D
F
A
C
C
A
A
A
A
F
What
I
can
do
is
just
finish
the
pr
to
get
like
as
far
as
possible,
with
accepting
as
much
as
I
can,
and
then
we
can
use
that
to
discuss.
A
All
right
that
sounds
useful,
I
feel
like.
I
can't
make
a
good
case
again
like
not
supporting
this
at
all
seems
probably
worse
than
the
fact
that
it's
gonna
be
not
great
or
like
going
to
be
inconsistent,
but.
G
A
Well,
I
don't
know
all
right,
let's
let
brian,
let's
let
ryan
experiment
and
we'll
come
back.
I
don't
think
this
is
what
I
expect
works,
no
matter
what
sort
of
struct
type
is,
but
the
fields
may
be
named
zero.
Also
people
can
drop
off
or
at
the
end
of
the
call.
Thank
you
all
for
coming.
A
This
is
in
expression
position.
I
don't
know
what
I
expect
in.
A
B
B
E
One
random
thing
since
you're
on
the
call
josh
sure
I've
put
a
here's,
how
the
the
try
stuff
could
be
edition
sensitive
in
the
lib
zulip
chat.
I
think
it
also
might
actually
be
pretty
reasonable.
It's
a
surprisingly
small
change.
G
Effectively,
how
we
could
allow
the
interoperability
with
option
and
result
with
none
error,
but
only
in
previous
editions
and
not
in
the
current
edition.
E
From
residual
I
can
we
can
make
a
new
version
of
it
with
a
blanket
input
from
the
common
one.
So
I
it's
looking
like
I've
put
a
link
to
the
commit
there.
If
you
want
to
see
it's
looking
like,
it
would
basically
be
able
to
be
communicated
as
there's
two
extra
impulse
in
old
editions,
which
I.
G
G
And
if
you
do
a
blanket
import
of
mod
sadness,
then
you
get
those
extra
impulse.
E
No,
it
would
just
be
there's
a
new
trade
in
there,
for
that
has
those
impulse
on
it,
so
2015
and
2018
would
use
that
version
of
the
tri-residual
trade,
and
I.
G
Okay,
I
think
I
get
it
now
so
from
residual
legacy
would
be
the
de-sugaring
in
previous
editions,
and
that
has
a
blanket
impul
for
anything
that
is
from
residual
non-legacy,
and
then
it
also
has
the
the
sad
impulse
that
we
wish
we
didn't
have
yeah.
G
Okay,
I
buy
that
that
will
need
some
careful
documentation
to
cover
that
case
of
like
here's,
where
you'll
see
this
weird
name
and
I
am
tempted
to
call
it
rather
than
like
from
residual
legacy,
I'd
be
tempted
to
call
it
like
from
residual
2015-2018
yeah
that
way
it's
more
self-documenting,
but
that
aside,
I
mean
in
much
the
same
way
as
I
find
your
whole.
Please
call
the
okay
or
method
type
there
very
amusing.
E
E
G
I
think
we
should
probably,
if
we're
going
to
do
that,
break
across
an
addition
for
the
d
sugaring.
We
also
need
to
re-raise
it
for
lang
as
well.
I
think
that
the
answer
for
do
we
mind
de-sugaring,
that
differently,
by
addition,
will
probably
be
yes,
but
we
should
raise
it.
Okay,.
G
Also,
let
me
I
have
some
and
I
had
an
idea
that
would
both
shorten.
G
Okay,
yeah,
if
you
were
going
to
be,
you
know,
giving
a
weird
name
to
something
anyway,
then
by
all
means
use
non-standard
style
so
that
it's
extremely
self-documenting
yeah
it'd
be
really
amusing.
If
we
had
a
sufficiently
like
raw
mechanism
for
identifiers
that
you
could
actually
stuff
a
space
into
that
identifier
or
a
dot,
please
call
dot
okay
or
open
print
close
per
end.