►
From YouTube: Safe Transmute / Typic Design Meeting (2020-07-01)
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
B
A
I
mean
we
can
talk
specifically
about
typic,
but
just
to
kind
of
kick
off
the
the
the
conversation
kind
of
in
general.
We
are
at
least
the
meeting
was
said
to
be
talking
about
safe
transmute.
It's
not
really
about
that,
although
what
we're
talking
about
kind
of
like
allows
you
to
do
safe,
transmute,
but
really
we're
talking
about
bringing
up
layout
and
kind
of
in-memory
representation
invariance
that
types
have
into
the
type
system
so
that
you
can
do
stuff
with
that
information,
one
of
which
is
transmutation.
A
It
happens
to
be
one,
that's
really
powerful,
but
there
are
other
things
that
are
sort
of
like
if
you
squeeze
your
eye,
is
hard
enough
and
think
about
it
in
a
certain
way
might
look
like
transportation,
but
most
people
don't
tend
to
think
of
them
that
way,
but
at
the
end
of
the
day
we
really
want
to
answer
the
question.
What
does
this
type
look
like
in
memory?
A
But
this
is
a
not
a
very
granular
way
to
do
things.
So
you
end
up
answering
small
questions,
but
never
really
like
being
able
to
fully
reason
about
types
layouts
and
then
the
tipic
way
is
really
like.
Let's
represent
this
types
layout
in
the
type
system,
so
that
we
can
have
kind
of
perfect
information
about
it
and
when
you
have
perfect
information
about
it,
then
basically
anything
that
is
answerable.
You
know
to
us.
Humans
can
also
be
answerable
to
the
type
system,
and
we
can
we
can
reason
about
things
that
way
anything
else.
C
Yeah,
that's
that's!
Basically,
it
and
I'll
have
that
the
approaches
aren't
actually
mutually
exclusive.
I
think
actually
started
because
I
was
hacking
on
zero
copy
and
trying
to
make
the
derives
better.
I
thought.
Well.
How
would
it
just
be
great
if
it
just
knew
the
types
layout
at
compile
time?
So
you
know
having
zero
copy
style.
Trades
definitely
is,
is
pretty
nice
as
an
end
user
for
some
things,
yeah.
A
Just
to
layer,
on
top
of
that,
like
most
of
the
time,
the
these
sort
of
very
coarse
traits
that
you
get
with
something
like
zero
copy
is
enough,
and
so,
if
you
want
to
answer
things
like,
can
this
type
B
safely
zeroed?
It
would
be
nice
to
just
have
like
okay?
Is
this
a
zero
zero
bull
thing
and
you
don't
need
to
know
kind
of
all
the
fine
details
as
the
types
layout
and
and
all
the
funny
questions
that
we
can
get
to
today?
That
you
have
to
know
about
you
just
want
to
know.
A
Is
it
zero
wool,
but
two?
There
is
a
way
to
kind
of
answer.
All
of
these
questions
all
at
once
and
that's
by
yeah
having
the
ability
to
reason
about
types
layouts
and
the
type
system
fully
and
so
yeah
I
think
we
do
how
we
end
up.
Actually
exposing
this
to
users
will
probably
be
a
combination
of
these
two
things,
most
likely
with
the
typic
way
being
kind
of
the
foundation
and
the
more
powerful
API
and
then
having
kind
of
shortcuts.
A
D
C
So,
typically,
just
TIPA
TIPA
cake,
safe
transmute,
very
literally,
so
it
does
safe
transmute,
which
boils
down
to
a
copy
zero
copy
has
because
of
its
very
specific
design
for
parsing
networking
package
is,
is
more
so
tuned
to
the
incremental
parsing
of
of
data
streams
and
when
you're
doing
that,
you
know
you've
kind
of
thrown
doing
one
big
mem
copy
out
of
the
window.
Anyways.
B
D
Well,
two
things
I
was
actually
asking
if
you
can
use
this
to
read.
One
of
these
read
a
structure
that
has
this
metadata
out
of
a
buffer
or
a
reader
or
similar,
using
that
metadata
to
do.
Okay,
I
want
to
read
this
whole
thing.
Little-Endian
or
I
want
to
read
this
whole
thing.
Big-Endian.
Please
convert
the
individual
pieces
that
if
there
were
enough
metadata
for
that,
there
would
obviously
also
be
enough
metadata
for
please
take
this
structure.
That's
currently
little-endian
in
memory
and
convert
it
to
big
endian
yeah.
C
B
B
A
Have
like
a
question
that
I
would
like
for
us
to
eventually
get
out
of.
This
is
I
I
think
that
the
approach
that
typically
is
taking
is
a
really
great
approach,
I'm
fairly
convinced
that
this
should
not
be
a
library
and
that
we
should
have
functionality
like
this
in
the
standard
library,
for
reasons
of
error,
messages
are
pretty
gnarly
and
typic.
This
is
very
unsafe.
What
we're
doing
here
and
anything
that
is
I
should
say,
stood
them.
D
A
A
C
C
Part
of
realizing
that
vision
requires
having
sort
of
global
knowledge
of
types
and
tipic
doesn't
have
that
right.
It.
It
basically
only
works
for
types
where
you've
annotated
it
with
the
things
of
the
proc
map.
Record
can
see
it
so
yeah
long-term,
realising
tipic
would
really
require
compiler
support
and
also
the
compiler
has
that
ground
truth
about
what
the
layout
looks
like
anyways
it'd
be
nice
to
build.
D
On
that
I
think
what
I
was
getting
at
was
in
some
way.
Is
there
a
very
clean
obvious
line
of?
If
the
compiler
did
this
much,
then
we
could
build
on
what
it
did
in
the
ecosystem
and
eventually
move
some
of
that
interested.
Or
is
it
necessarily
the
case
that
the
compiler
support
and
the
libs
support
would
need
to
go
in?
At
the
same
time,
no
I
think.
C
Yeah
I'll
loop
back
around
to
this
later
on,
but
I
think
the
okay,
a
really
promising
path
would
be
to
introduce
zero
copy
style
traits
into
the
standard
library,
annotate
them
with
the
marker
attribute,
and
that
way
we
would
be
free
to
have
these
be
unsafe.
Traits
you'd
be
free
to
have
an
intelligent
automatic
implementation
of
these
traits
as
the
compiler
got
smarter,
but
until
then
libs
could
pick
up
some
of
the
slack
and
they
would
have
a
standardized
API
to
program
against.
C
Stuff
covering
it,
okay,
so
can
y'all
see
my
screen:
okay,
yeah
great,
so
this
is
typically
the
example
here
sort
of
boils
it
down.
You
simply
replace
your
reference
key
attribute
with
a
typic
reference,
the
attribute
that
matches
rep
receipt
exactly
and
just
by
doing
that,
it's
a
small,
asterisk
typic
has
deep
knowledge
of
your
type,
can
compute
the
layout
of
it
at
compile
time
and
therefore
implement
traits
based
on
its
layout.
C
So
the
one
extra
thing
here
is:
you
know
it's
not
it's
not
great.
C
You
assert
transmittable
from
so
you
say:
oh,
my
self
type
is
always
going
to
be
transmittable
from
this
other
type
and
transmute
into
which
is
the
inverse
of
that
stable
API
just
implements
those
traits
for
a
type
on
itself.
So
it's
a
way
of
saying:
I'm
really
never
ever
going
to
touch
this
type
and.
C
This
is
one
of
the
newer
parts
of
typic,
but
it
seems
to
have
enough
flexibility
to
express
some
really
ambitious.
Api
stability
guarantees.
You
can
basically
say
things
like
you
know:
I
want
to
give
myself
the
freedom
to
add
a
field
where
there's
padding
right
now
in
the
future,
just
by
choosing
your
new
type
skier.
C
C
C
The
the
rest
memory
model,
so
it's
it's
sound
to
merely
do
the
transmute,
but
it
not
might
not
be
safe
to
actually
use
that
value
afterwards,
especially
if
the
type
has
internal
invariance
that
it
relies
on
so
unsound.
Transmutation
is
realized
with
the
trait
unsafe
transmitted
from
there's
also
for
convenience,
unsafe
trans
being
into.
C
Unsafe
transmit
from-
and
this
is
the
definition
of
unsafe
transmit
from
so
yeah.
It
basically
gives
you
a
unsafe
transmit
method
on
a
type
now
one
of
the
quirks
of
unsafe
trampy
from
is
this
options
parameter
here,
and
so
what
I
found
is
that,
quite
often,
you
actually
want
to
relax
some
static
guarantees
that
you
know
if
it
could
otherwise
perform.
For
example,
you
might
say
you
know,
don't
check
out,
don't
check
that
the
alignment
is
verified
statically
right.
C
C
So
here's
an
example
of
bite
map,
white
mug
strike
a
stress
function,
implemented
in
the
typic
style,
and
for
this
the
try
indicates
that
if
the
pointer
doesn't
match
the
alignment,
requirements
of
the
destination
type
will
return
a
nun
instead.
So
we
want
to.
We
want
to
ask
today:
is
it?
Is
it
safe
to
do
this?
Transmutation,
neglecting
alignment,
and
so
it's
up
to
us
in
our
implementation
to
perform
that
check
ourselves.
C
B
C
C
C
D
B
C
C
C
C
D
Will
fail
to
compile,
but
it's
not
that
it
will
ever
compile
and
then
be
wrong
yeah.
You
know,
I'll
just
feel
it
well,
that
makes
sense.
Yeah
I
was
going
to
ask
is
so
the
proposal
here
for
transparency
is
effectively
that,
if
you
use
unsafe
you're
allowed
to
violate
the
spec
of
whether
something's
pub
or
not
exactly.
C
C
Which
lets
so
by
default
typically
only
accepts
transmutations
that
are
guaranteed
to
be
sound.
So,
for
example,
you
can't
do
you
wait
to
bool
by
default,
but
if
you
pass
in
neglect
validity,
it
will
let
you
do
that,
because
you
are
taking
it
on
yourself
to
check
that
invariant.
D
C
C
D
C
C
D
C
D
D
C
C
B
B
D
I'm
trying
to
understand
that
particular
item
in
detail,
because
I
find
that
that's
one
of
the
most
common
cases
where
I
would
like
a
safe
transmute
is
specifically
that
I
have
a
slice
of
bytes
and
I
went
to
a
struct,
or
vice
versa.
It's
pretty
clear
from
what
you're,
showing
that
the
vice
versa
is
straightforward.
Here,
a
modulo
you
have
to
not
have
any
padding,
but.
B
C
C
Is
the
question
and
well
that
wouldn't
quite
be
a
transmit
because
ass
life
is
going
to
be
a
fat
pointer,
and
so
that's
gonna
have
a
different
layout
than
a
normal
thing.
But
if
you
have
a
reference
to
an
array
of
fights,
that's
as
least
as
large
as
the
struct,
you
want
to
transmute
that
you
know
get
a
reference
to
that
struck
into.
B
C
C
This
is
the
case
where,
because
slices
are
involved,
there's
some
infallibility
based
on
the
size
of
the
slice
and
so
forth,
and
so
you
basically
use
transnih
into
as
a
we're
bound
to
to
do
those
static
checks
for
you.
But
in
the
body
of
this
function
we
don't
actually
call
transmute
into
anywhere
because
slices
have
these
this
special
memory
layout
about
them.
E
So
I,
actually
I,
don't
know
if
this
is
backing
up
too
far,
but
I
I
think
that
the
existence
of
this
crate
is
super
interesting,
because
when
Josh
was
originally
writing,
zero
copy
I
told
him
like
he
started.
Writing
something
that
looked
like
this
and
I.
Basically,
like
did
oh
man.
This
is
way
too
complicated.
E
Try
it
like
all
that
you're
really
trying
to
do
is
go
back
and
forth
between
references
to
like
arrays
of
memory
like
just
the
u-ace
license
and
data
structures,
and
so
that's
how
zero
copy
got
turned
into
what
is
now
it's
like
from
bytes
and
as
bytes
and
yeah,
and
then
a
little
bit
of
munching
about
for
worrying,
about
alignment
and
and
I
think
that
you
followed
up
on
the
internals
thread
that
was
discussing.
You
know
something
more
like
this.
That
was
actually
like.
Hey.
How
do
we
turn?
E
E
Like
what
I
probably
should
have
read
that
internals
thread
again
before
this
meeting
but
I
don't
remember,
super
well
all
the
sort
of
use
cases
that
that
was
targeting
and
like
sort
of
the
why,
behind
this
extra,
like
functionality
of
being
able
to
turn,
you
know
a
struct
into
a
different
struct
where
they're,
not
necessarily
you
know,
lacking
and
padding
or
not
necessarily,
you
know
missing
these
other
things,
but
actually
just
that
they
have
the
same
layout
as
this
other
start.
Maybe
you
can
elaborate
on
that
a
little
bit
yeah.
C
So
this
entire
tree-
it
is
also
the
fault
of
Josh
grumbling
to
me
about
their
got
these
faults,
but
I'm
not
I'm,
not
really
a
systems
programmer
I
do
Education
Research,
and
this
was
just
nerd
sniping.
So
I
can't
speak
from
personal
experience
about
all
these
cases.
I
do
have
some
in
mind
specifically
so
tight
punting
is
reasonably
common
in
in
C
and
C++
and
typic.
C
F
Tyler
one
particular
case
that
comes
to
mind,
for
me
is
the
people
who
talk
about
gamedev
things
really
like
taking
vectors
of
points,
trucks
and
turning
them
into
vectors
of
s32
or
arrays
of
s
32s
or
slices
of
that
thirty
twos,
and
things
like
that.
Where
bites
you
I
guess
you
could
sort
of
go
through
bites,
but
it's
kind
of
awkward
as
you
lose
them.
You
lose
the
alignment
statically
with
you,
convert
yourself
into
bytes
places
in
the
middle.
D
Right
I
can
see
how
this
would
work
really
well
for
that
as
well.
It's
once
you
showed
the
higher-level
slice
wrapper.
It
was
clear
that
you
could
also
do
things
like
I
want
to
go
from
a
slice
of
in
four
vectors
of
f32
to
a
slice
of
four
in
f/32
s.
It's
there's
enough
information
here
to
allow
for
that.
With
compiled
time
analysis,
it
looks
like
I
I
would.
E
Respond
in
Scotland
I
think
that
that's
one
of
the
use
cases
that
I
would
point
you,
as
solvable
with
from
bytes,
like
the
type
that
you're
converting
from
is
from
bytes
and
that
type
that
convert
you're
converting
into
is
as
bytes
and
the
two
have
the
same
alignment,
which
is
like
a
little
bit.
I,
don't
know,
I
think
that's
a
little
bit
of
a
simpler
constraint
to
satisfy.
E
D
Yet
this
is
really
promising
in
terms
of
like
now
that
you've
shown
the
higher
level
bits.
It
makes
more
sense
what
the
lower
level
metadata
and
type
data
is
allowing
you
to
implement
safely.
Atop
of
that,
so
I
think
this
is
definitely
solving
the
problem
and
to
close
the
earlier
thread.
Your
higher-level
demo
fully
answered
my
question
about
whether
this
will
solve
the
use
case.
F
E
That's
interesting,
I
still
think
about
those
is
like
all
relatively
like
a
simpler
case
of
this,
because
you're
not
having
to
deal
with
the
like
same
place,
padding
issue
but
you're
right
that
it
is
like
sort
of
a
more
it
is
a
more
complex
structural
invariant
than
just
you
know.
Is
this
type
interconvertible
tune
from
bytes
right.
C
Yeah
one
more
thing:
there's
another
complicated
case
that
to
fix
all's
that
isn't
padding
related
and
this
isn't
merged
into
the
main
branch.
Yet
because
it's
really
hard
but
typical
handle
transmutations
between
enums,
two
and
it'll
reason
correctly
about
the
discriminant
values
of
of
the
variants
and
so
forth.
C
Well,
yeah,
actually,
that's
a
shortcoming
of
tipping
right
now.
The
other
case,
we're
tipping
with
immense
effort
could
be
a
little
smarter
is
option
like
enums
have
some
guarantees
about
their
layouts
right.
D
It
sounds
great,
so
yeah
I
think
to
close
off
that
thread
so
that
we
don't
continue
to
go
down
that
rabbit
hole.
Do
you
believe
that
it's
possible
to
solve
using
the
tipic,
something
like
safe,
transmute
to
or
from
option
of
non
zero?
You
32
versus
you
32
or
similar
things
like
an
enum
with
a
discriminant
and
the
values
corresponding
to
that.
C
C
C
Yes,
absolutely
so
the
theme
this
could
really
help.
C
Me
pull
up
an
example,
I
whipped
up
last
month.
I
was
really
excited
about,
so
it
doesn't
quite
work
anymore,
oh,
but
for
a
brief
period
of
time
it
was
possible
to
implement
traits
based
on
whether
a
constant
Eirik
predicate
was
satisfied
and
in
the
far-flung
future.
I
see
this
is
basically
the
future
of
tipic.
You
know
the
compiler
exposes
a
unstable
intrinsic
in
the
form
of
a
product
called,
you
know,
can
transmute
that
takes
in
two
types
as
its
parameters
and
returns
a
boolean
and
then
there's
this
public
facade.
C
That's
you
know,
implemented
in
a
blanket
manner,
based
on
that
that
you
know,
based
on
the
state
of
cosmetics,
I
see
that
as
kind
of
a
far
future
thing,
but
I
do
have
an
idea
of
how
we
might
work
incrementally
towards
that
point,
while
still
delivering
value
to
and
users
on
a
more
reasonable
timeframe,
and
that
is
exposing
zero
copy
like
trade.
C
So
so
here's
how
you
implement
as
bytes
you
know
just
using
typic,
except
you
know
this
is
sort
of
a
very
smart
as
bytes
that
can
work
in
a
lot
of
cases
where
zero
copy
doesn't.
C
D
C
Can
transmute
predicates
I
mentioned
would
be
immediately
helpful
because
even
bounce
generics
isn't
quite
there
yet
and
I
can't
implement
traits
based
on
it.
That
would
let
me
and
zero
copy,
and
everyone
else
have
you
know
unlikely
only,
but
still
a
way
of
testing
their
own
implementations
on
compiler,
ground
truth
right
and.
C
Having
the
compiler
tell
you
in
it
with
an
intrinsic,
you
know,
something
like
can
transmute
gets
closer
to
being
a
reality,
yeah
it.
So
it's
already
very
close
I
feel
like
because
I
can
already
you
know
last
as
of
last
month.
I
could
already
do.
You
know,
implement
a
trait
based
on
whether
the
alignment
of
a
thing
was
one
which
was
awesome.
F
Work
for
scoping
how
how
much
do
we
want
to
try
and
do
something
for
the
front
bytes
to
bytes
thing
earlier
or
do
we
want
to
just
try
and
do
the
whole
here's
the
predicate?
We
want
the
whole
thing
because
at
least
I
think
from
bytes
could
be
done
in
the
library
today.
I
think
with
auto
trades
right
from.
C
F
F
D
D
E
C
So
I
think
having
of
from
bytes
as
bytes
as
merely
trait
definitions
in
the
poor
library,
even
without
a
preference
nation
backing
them
up
would
be
immediately
useful.
Those
traits
appear
over
and
over
again,
and
so
many
you
know
safer
transitive
libraries
that
just
having
a
standard
that
they
could
all
implement
against,
would
be
helpful.
I
think
there.
C
Right
right
now,
that's
tends
to
be
something
they
already
have
to
adhere
to,
because
these
crates
usually
take
the
form
of
a
trait
definition
that
happens
in
one
crate
and
a
derive
macro
that
you,
you
know
you
annotate
your
own
types
with
so
they're
already
implementing
against
a
foreign
trait
all
I.
A
A
Just
just
a
shout
out
real
quick
to
it,
I
have
a
repo
that
is
exploring
this.
It's
called
the
mem
markers
repo.
It's
basically
a
place
to
explore
what
types
are
possible
like
for
these
kind
of
marker
traits
that
you
would.
You
would
have
like
from
two
bytes
two
bytes
zero
of
all
things
like
that.
It's
a
way
of
trying
to
explore
what
types
it
makes
sense
in
the
centered
library
to
to
implement
those
on.
So
there
has
been
linking
in
there
one.
F
I
was
it's
feels
to
be
like
the
there's.
One
interpretation
of
this
that
is
like
Ken
Lang
expose
some
sort
of
type
trait
on
things
that
are
that
are
valid
with
any
bit
pattern
or
that
never
have
any
undefined
bits
in
them.
And
then
those
are
the
core
constraints
on
which
a
library
would
want
to
implement
their
support
for
doing
things.
But
then
that
becomes
a
market
rate
with
no
methods
on
it
at
all.
And
then
it's
up
to
some
other
library
to
make
from
bytes
and
to
bytes
in
a
nice
way.
Yeah.
C
C
F
C
C
Yeah,
it
makes
my
life
a
little
more
complicated
typic
until
recently.
Actually,
it
no
still
does
not
expose
its
its
bite
level,
representation
of
types
layouts
and
the
reason
for
that
is
because
I
change
it
all
the
time
I
think
would
be
hard
to.
You
know
envision
sort
of
infinitely
into
the
future.
C
B
F
C
But
that's
actually
one
of
the
cool
things
that
you
get
from
having
trans
need
from,
because
you
can
define
a
type
that
has
the
properties
you
know
about
without
having
to
know
like
actually
how
the
compiler
is
reasoning
about
its
layout.
You
know
it's
layout
sort
of
at
a
high
level
and
you
can
use
transmit
from
as
a
trait
bound
to
say
things
like.
C
You
know
if
you
have
a
type
where
you
can
always
transmute,
you
know
from
A
to
B
and
always
from
B
to
a
you
know
for
a
certain
definition
of
equivalent
the
types
are
equivalent,
so
that.
B
It's
it's
57
after
the
hour
and
we
have
a
lie
at
least:
have
a
hearts
double
but
I've
been
taking
some
notes.
Maybe
people
can
drop.
What
the
heck
I
can
be
in
the
stream
will
can
drop
any
comments
they
want.
I
think
it
seems
like
we
got
to
the
purple,
like
the
immediate
proposal,
for
our
next
step
is
to
add
these
traits
right.
That's
kind
of
your
proposal
John
at
least
yep.
C
B
B
C
The
market
rates
things
seems
purely
at
the
moment,
if
we're
not
thinking
of
clever
implementations
like
getting
both
of
that.
The
predicate
thing
which
I
also
would
really
like
to
have
so
the
intrinsic
predicate
on
can
transmute
yeah
I
I
want
to
make
sure
we
don't
drop
that
ball,
because
that
would
be
very
useful.
Just.