►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/technical-details-of-the-solidity-compiler/
Recent updates about Solidity and plans for the future.
Speaker(s): Daniel
Skill level: Advanced
Track: Developer Infrastructure
Keywords: Solidity
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
For
yeah
over
four
years
now
and
yeah,
originally,
the
plan
was
for
the
store
to
be
held
by
Chris,
who
couldn't
make
it
to
Bogota.
So
I
have
to
improvise
a
bit.
I
brought
a
lot
of
code
Snippets,
which
will
explain
what
we
have
currently
in
the
compiler,
currently
the
state
of
the
language
and
where
we
are
headed
with
it,
yeah
I!
Guess
you
if
you
are
familiar
with
Trinity,
which
I
hope
most
of
you
are.
We
probably
know
new
doubles
by
now.
A
It's
been
around
for
for
a
while,
and
it's
a
very
highly
appreciated
feature
from
our
impression,
which
yeah
I
still
will
quickly
explain
how
they
work.
That's
the
owner
of
arrival
here
is
looks
like
a
state
variable,
but
it's
not
a
really
proper
State
variable
in
storage,
but
a
mutable
variable
which
can
only
be
assigned
to
Once,
In,
The
Constructor
and
then
can
use
this
many
times
as
one
wants
read
only
in
the
runtime
code
of
the
contract,
but
there
it's,
the
access
is
very
cheap.
A
It
doesn't
require
an
S
load,
but
it's
basically
in
line
in
the
code
as
if
it
was
a
literal,
so
yeah
you'll
probably
know
this
and
people
liked
it
a
lot
and
an
apparent
and
a
very
obvious
extension
they
asked
for
is
why
do
we
only
support
that
for
Value
types?
That's
the
Restriction.
You
had
so
far
that
it's
only
integers
on
the
addresses,
but
not
arrays,
of
things,
for
example,
for
example.
So
this
was,
for
example,
it's
taken
from
a
GitHub
issue.
A
That
I
think
opens
apple
and
open
with
us
to
yeah
ask
for
an
array
of
immutables,
which
would
then
yeah
be
initialized
by
index
accessing
and
otherwise
work,
just
as
as
one
is
used
with
immutables
and
we're
working
towards
that
end.
But
there's
some
issues
with
that.
So
I
mean
we
have
these
assignment
here,
where
randomly
assigned
into
elements
of
this
array
and
in
general
I
cannot
check
that
this
is
really
assigned
only
once
I
mean
the
question
is:
is
there
still
an
immutable
thing
in
that
sense?
A
Also,
if
I
start
having
a
race
as
a
mutables
I
will
want
to
have
local
references
to
them,
which
I
could
then
reassign.
So
if
I
keep
the
name
immutable,
I
just
change
what
this
points
to
so
this
is
really
it
doesn't
look
immutable
immutable.
It
doesn't
fit
this
concept
anymore.
Probably
so,
let's
yeah,
let
me
explain
a
bit
further.
A
How
Universe
actually
work
in
the
Constructor
owner
is
actually
a
position
in
memory,
so
we
store
whatever
you
write
to
this
variable
in
memory
and
then
when
the
actual
runtime
code
of
the
of
the
contract,
part
of
deploy
is
copied
to
memory
to
be
returned
by
The
Constructor.
We
fill
in
from
this
network
location
into
the
byte
code,
the
value
that
is
there
which,
in
the
end,
results
in
the
runtime
code
to
actually
have
it
as
a
literal
in
the
bytecode.
A
So
that's
the
Rival
in
the
Constructor
actually
is
a
memory
reliable
in
runtime.
It's
actually
something
that
lives
in
code,
but
filling
in
literal
values
in
some.
So
basically
the
push
argument
into
the
bytecode
won't
work
anymore
for
dynamic
types.
If
you
have
statically
sized
arrays,
we
could
still
do
that
and
we
probably
will
for
efficiency
reasons,
but
at
least
for
dynamic
types
to
go
full
way.
We
cannot
do
that
anymore
because
we
don't
know
the
length
of
the
thing,
so
we
can't
reserve
space
in
bytecode
for
that.
A
So
instead
we
need
to
rely
on
code
copy
and
yeah
I
already
mentioned.
We
will
probably
want
to
pass
the
immutables
by
around
by
reference.
We
will
want
to
slice
them
which,
if
you
think
about
all
of
that
together,
makes
immutables
not
an
annotation
for
a
staple
arrival
anymore,
but
it
will
become
a
proper
whole
data
location.
A
So
this
will
probably
look
like
this.
In
the
end,
as
I
said,
the
drive
in
the
end
will
live
in
code,
so
code
and
the
op
code
that
will
access
it
is
code
copy.
So
code
is
a
natural
name
for
these
things.
So
here
I
have
a
data
arrival
that
bites
the
dynamic
array
in
code,
which
I
can
then
in
the
Constructor
just
treat
like
any
old
memory
variable
assigned
to
it,
modify
it
freely.
You
can
drop
the
requirement
that
it's
only
written
to
Once
In
The
Constructor,
because
that
was
always
an
artificial
requirement.
A
This
will
be
a
bit
tricky
to
write
to
type
check
in
the
end
because
yeah
in
the
Constructor,
it
is
a
memory
reliable
in
the
runtime
code,
it
vs
differently.
So
if
the
Constructor
calls
functions,
we
need
to
type
check
everything
twice,
but
we
have
different
costs
for
a
refract
factor
in
the
type
Checker
to
actually
do
that
as
well.
So
we
will
do
that
and
there's
still
some
considerations
of
gas.
A
Invite
code,
if
not,
we
will
probably
yeah
code
copy
either
in
an
entire
memory
or
if
you
just
need
a
snippet
of
a
dynamic
array,
called
copy
to
scratch,
space
and
M
load
from
there.
That
will
still
be
significantly
cheaper
than
anything
in
storage,
okay,
yeah.
That
was
the
first
topic.
I
wanted
to
talk
about.
A
The
second
thing
that
you
may
have
noticed
in
the
recent
versions
is
our
move
to
to
allow
user-defined
value
types
go
to
test
case,
for
this
concept
was
always
fixed,
Point
types
which
we
decided
to
not
Implement
as
a
first
citizen
type
in
the
in
the
type
system,
but
to
build
the
infrastructure
to
Define
it
as
a
user-defined
type.
Yeah
I'm,
assuming
that
you're
familiar
with
those
so
I,
won't
go
into
that
much
more
detail
in
the
basic
concept
which
what
we
recently
added
or
more
recently
added,
is
This
Global
keyword.
A
You
see
in
the
first
using
statement,
which
means
that
currently,
a
using
statement
is
only
locally
effective,
whereas
a
using
statement
with
a
global
at
the
end
will
only
be
allowed
in
the
very
same
source
file
in
which
you
define
the
type.
But
we'll
have
that's
the
effect
that
wherever
the
type
is
available,
the
functions
you
bound
to
the
type
will
also
be
available.
A
So
this
is
what
you
can
do,
then,
in
the
end,
practically
to
write
type
libraries
when
you're
in
that
Library
Define,
the
type
equipped
with
some
functions,
and
then
anyone
importing
the
type
only
can
still
use
all
the
functions
on
that
still,
of
course,
one
major
inconvenience
with
that
for
defining,
for
example,
fixed
Point
times
that
are
actually
nice
and
usable,
is
that
we
have
only
functions
in
that
can
be
defined
and
equipped
to
the
type,
but
the
using
statements,
which
is
what
we
will
soon
change.
So
this
is
open
PRS.
A
Currently
that
are
under
review,
which
will
probably
yeah
in
finite
amount
of
time
we
actually
merge
and
come
through,
which
will
allow
user-defined
operators
and
literals
in
in
the
first
versions
in
a
very
limited
setting.
So
the
addition,
for
example,
can
only
be
between
the
two
between
two
expressions
of
the
type
that
you
define,
such
that
it's
not
getting
messy
and
you
know
no
longer
know
what
function
will
actually
be
executed.
A
A
Yeah
the
desire
to
have
proper
aggregate
algebraic
data
types
in
general,
so
the
more
user-defined
data
types
we
have
the
easier
it
is
to
like
a
usable
code
and
yeah.
There's
questions
about
that.
For
example,
where
data
locations
would
go
current
if
data
locations
are
associated
with
variables
and
not
types
which
makes
that
a
hassle
which
we
will
also
probably
change
for
independent
reasons,
but
yeah
I
mean
you
may
see
where
I'm
going
with
this.
A
If
we
have
all
these
kinds
of
types
and
maybe
also
user-defined
containers
and
all
that,
it
will
no
longer
be
feasible
to
to
write
functions
to
cover
all
these
types
and
there's
several
functions
for
all
these
types.
So
all
this
increases
the
need
for
having
a
construct
of
generics
in
the
language
which
has
been
long
an
idea
to
introduce
with
the
language
and
which
yeah
we're
finally
now
making
moves
towards,
but
yeah
this.
A
A
For
example,
add
mode
is
a
simple
example
which
can
then
actually
be
implemented
in
inline
assembly,
with
additional
checks
that
works
to
reduce
the
footprint
of
the
compiler
and
to
yeah,
make
it
easier
for
people
to
inspect.
What's
actually
happened
and
to
extend
it
even
but
the
problem
there
again
is.
A
So
the
end
go
over.
The
standard
library
is
reduce
the
language
to
a
small,
simple
core
language
and
have
most
of
the
current
features
that
we
have
in
the
language
defined
in
a
standard
library
that
is
written
in
solidity
can
be
quickly
iterated
on
can
be
extended
by
the
community
and
can
be
audited
and
so
on
and
so
forth.
A
But
to
get
to
that
point
in
full,
we
need
generics.
So
the
idea
is
to
yeah
get
inspired
by
a
nice
system
of
generics
which
is
based
on
a
logically
grounded
type
system.
We
have
products,
I
have
some
types
function,
types
which,
if
you're
a
mathematician
or
category
theorist,
the
type
system
will
probably
form
a
partition
closed
category,
which
is
how
these
things
work,
usually
in
properly
designed
to
know
languages
like
Haskell
or
like
the
trade
system
in
rust,
or
the
general
system
rust
and
yeah.
A
We
will
have
polymorphic
functions
that
can
take
arbitrary
types
and
yeah
ad
hoc
polymorphism
using
type
glasses
or
that's
in
Rust.
Maybe
if
people
are
more
familiar
with
that
great
and
yeah,
we
will
also
for
this
to
work
out.
You
kind
of
need
to
go
all
in
on
it
and
or
go
for
the
code
the
whole
way.
So
we
will
also
have
algebraic
data
types
and
yeah.
All
of
this
will
also
be
only
really
useful
if
you
have
compile
time.
A
Constant
expression
evaluation
because
you
will
in
generic
functions,
have
yeah
constructed
parameters
that
should
be
evaluated
at
compile
time
so
yeah,
that's
also
something
we
will
have,
which
is,
as
I
said
earlier
for
the
code
data
location,
we
will
need
to
refactor
the
type
Checker
to
have
VMware
flexible
for
this.
We
will
need
that
as
well
and
yeah.
A
However
long
it
will
take
so
yeah.
The
go-to
down
to
earth
example
of
a
use
of
generics
is
something
like
a
resizable
array,
some
container,
which
yeah
in
this
case
it's
just
an
array
that
if
you
want
to
append
something
to
it
and
it
see,
the
array
is
already
full.
You
just
reallocate
with
twice
the
size
copy
things
over
and
yeah.
Otherwise
you
can
just
add
the
element
to
the
end
of
the
array
and
yeah.
Then
we
can
also
Define
an
index
access
as
a
user-defined
operator,
which
will
then
have
this
thing
actually
work
nicely.
A
A
If
one
wants
to
take
this
upper
notion
all
the
way,
one
can
actually
then
think
about
even
defining
the
most
basic
types
in
solidity
itself.
This
would
be
the
definition
of
the
current
representation
of
memory
arrays
in
solidity,
written
as
user-defined
type
with
the
customly
defined
index
access
to
it.
So,
in
the
end,
for
any
bass,
type
of
memory
array
is
just
one
stack
slot.
A
You
refer
to
memory
arrays,
just
as
one
stack
slot
be
index
access
by
it
by
fetching
I
mean
this
desktop
points
to
some
memory
area,
where
there
is
the
size
of
the
array
and
followed
by
the
data.
There's
the
current
layout
at
least
and
yeah
in
index
access.
We
can
just
fetch
the
size
through
the
bounce,
checking
and
fetch.
A
We
had
often
the
request
to
allow
slicing
for
memory
types
which
we
can't,
because
the
representation
I'll
show
here
doesn't
allow
it,
since
we
expect
the
size
to
be
at
the
first
memory
offset
where
the
memory
pointer,
that
is,
the
representation
type
of
this
points
to
is
the
size
we
can
just
slice
away
from
the
first
element
for
that
to
work.
Memory
arrays
would
have
to
work
different.
Similarly
to
call
data
types
there
you
have
offset
and
size
on
stack.
A
A
One
of
them
is
pointer
to
data
area,
the
other,
so
it's
the
size
and
yeah
have
a
similar
definition
as
before
slide
changes,
but
a
few
Source
changes
in
our
standard
Library
would
then
be
the
same
as
changing
the
entire
layout
of
of
memory
types,
which
would
be
yeah
month
of
month
of
work.
Why
we
maintained
everything
hardcoded
in
the
compiler.
A
Of
course,
it's
all
the
disadvantages.
If
we
actually
keep
this
extremely
generic,
like
that,
we
will
lose
semantic
information
that
will
actually
make
memory
optimization
harder
because
yeah,
but
the
compiler
sees
it's
just
a
bunch
of
Stack
slots.
There's
no
idea
that
that's
actually
memory
areas,
we're
talking
about
that
are
allocated
may
only
be
allocated
temporarily
and
stuff
like
that.
A
So
I'm
not
sure
whether
we
will
actually
go
this
far
and
if
so,
we
would
maybe
probably
do
this
in
a
yeah,
compiler
internal
manner,
where
we
will
still
assume
certain
semantic
properties
about
these
functions
without
supporting
similar
optimizations
that
we
can
do
if
we
know
what
these
things
do
in
their
random
user
code,
but
yeah,
why
did
I
say
stack
slot
all
the
time?
That's
yeah,
maybe
obvious,
but
just
to
mention
the
stack
slot
would
be
the
one
primitive
type.
A
Maybe
apart
from
from
product
types
and
even
the
basic
integer
types
size,
initial
types
we
have
right
now
can
be
defined
generically
just
yeah.
Like
the
other
cases
we
had
so
I
mean
this
will
really
reduce
the
footprint
you
can
hear
could
also
then
distinguish
between
types
that
are
checked,
arithmetic
and
unchecked
arithmetic
by
having
very
few
functions
that
are
generally
written
and
yeah
so
yeah,
but
not
to
give
to
make
you
expect
this
to
happen
too
soon
we
are
still
in
early
design
phase
for
generics.
There's
a
lot
of
questions.
A
This
is
a
very
complex
thing
to
do,
and
a
very
dangerous
thing
to
do,
because
yeah
all
of
this
needs
to
be
biologically
well
defined,
to
not
bite
in
the
back.
In
the
end,
so
I
mean
we
will
take
some
time
to
design
this
properly
and
syntax
is
also
a
question.
That's
very
much
differing
opinions
on
how
the
Syntax
for
these
kinds
of
things
will
end
up
being
I'm.
Not
that
concerned
by
that
now.
A
I
would
first
want
to
get
the
semantics
right,
but
eventually
we
also
need
a
good
Syntax
for
it
and
yeah
what
I
just
said.
We
need
to
decide
what
to
do
with
this
trade-off
between
making
this
the
language
really
self-defined
in
the
in
the
very
deepest
sense,
or
to
have
some
fixed
functions
which
are
fixed
in
the
compiler,
which
means
we
can
assume
that
semantics
or
there
are
compromises
between
that,
but
we'll
see
so
yeah.
To
summarize
what
I
was
talking
about
and
what
I
wasn't
talking
about,
we
will
still
do.
A
Hopefully
we
will,
in
the
future,
try
to
allow
more
pre-competation,
either
in
the
Constructor
by
the
coated
location
or
in
compile
time
by
compiler.
Constant
expression,
evaluation,
which
is
something
yeah
a
lot
of
people
have
asked
for
and
which
obviously
makes
it
easier
to
write
things
in
that
you
don't
need,
for
example,
magic,
constants,
embedded
in
a
contract
or
whatever,
because
you
can
compute
them
on
the
fly
without
it
costing,
and
he
had
a
huge.
A
A
huge
topic
for
the
future
will
be
to
make
the
language
extensible
and
self-defining
by
means
of
improving
user-defined
data
types,
pushing
the
standard
library
and
making
a
move
for
generics.
But
we
also,
of
course,
can't
just
ignore.
Is
that
we're
still
wasting
a
lot
of
memory?
I
mean
whoever
has
used
memory
and
solidity
will
know
that
yeah,
we
basically
don't
free
memory
which
for
a
long
time,
wasn't
the
main
concern
but
in
the
meantime,
is
very
huge
pain
point
in
yeah
for
cost
of
contracts.
A
There
were
several
approaches
we
discussed
so
far
for
improving
the
situation.
There
we
a
long
time
we
wanted
to
deal
with
this
on
the
Dual
level.
It
turns
out
that
may
not
be
as
simple,
so
maybe
we
will
move
actually
to
analyze
the
solidity
which
has
the
properties
right
there.
We
shied
our
way
of
doing
that
for
facility
being
the
more
complex
thing
to
analyze,
but
maybe
it's
fine.
We
will
see
and
yeah.
A
We
will
also,
of
course,
try
to
move
completely
towards
via
our
core
generation,
but
we
have
some
burdens
there
to
overcome
still
like
the
performance
of
the
optimizer,
better
tooling
support.
You
still
need
to
Define
got
the
background
data
for
the
tooling
tooling
to
consume,
to
actually
make
the
experience
as
nice.
A
If
you
want
to
give
us
any
feedback,
help
us
with
designing
generics
or
criticize
what
we
are
planning
and
saying
we
are
crazy
to
do
with
any
of
that
reach
out
to
us.
That's
the
channels
we've
just
said
and
yeah.
Thank
you
yeah.
It
used
to
be
the
case
that
the
compiler
has
two
back
end
paths
at
the
moment,
so
I
mean
it
used
to
be
the
case
that
solidity
was
directly
translated
to
evm
bytecode
and
then
only
of
the
Omni
optimizations
that
took
place
were
on
the
bytecode
level.
A
For
the
past
years.
We
have
moved
away
from
that
and
have
a
different
new
code
generation
pipeline
that
translates
solidity
first
into
Yule
into
an
immediate
language
which
preserves
some
structure
and
which
allows
for
more
complex
optimizations
for
inlining,
more
analysis
and
then
only
to
translate
Yule
to
evm
bytecode
as
a
second
step
which
can
reduce
gas
costs
significantly
in
some
cases.
In
some
cases
it's
the
same
as
before,
but
yeah
and
yeah
the
new
pipeline,
the
Via
IRS
via
the
intermediate
representation,
so
compilation
via
you.
B
Thank
you
for
the
talk
you
mentioned
generics
I'm
wondering
if
you
could
speak
to
how
you're
planning
on
implementing
that,
whether
you're
going
through
monomorphization,
because
I
worry
that
the
code
contract
size
will
balloon.
If
you
start,
you
know
doing
the
C,
plus
plus
style,
duplication
of
implementations
or
if
there's
some,
you
know
uniform
representation,
you
can
do
a
la
la
ocamel
or
you
know,
Java.
A
I
think
there's
not
much.
You
can
do
actually
I
mean
the
generics
of
C
plus
are
different
in
the
sense
that
they
are
analyzed
differently
and
you
only
get
errors
in
on
instantiations,
but
we
will
still
need
to
instantiate
and
generate
code
for
each
specific
case,
but
that's
not
worth
a
worse
than
what
you
get
now.
What
you
get
now
is
writing
by
hand
for
different
types,
different
functions
that
would
end
up
separately
in
by
code
so
yeah,
it's
not.
Nothing
is
worse
than
that.
That's
a
duplication
in
code
and
in
byte
code.
C
A
Good
question
I
would
I
would
think
that
the
yeah
down
to
earth
go
to
smart
contract.
Writer
will
not
bother
with
this.
It's
mainly
something
for
us
for
defining
a
senate
library
and
for
people
writing
libraries
to
support
smart
conflict
developer.
First,
so
I
mean
the
language
supporting
generics
and
having
generic
types
doesn't
force
you
to
use
them,
and
it
doesn't
mean
that
anybody
has
to
use
them,
but
it
will
make
a
language
in
the
the
evolution
of
a
language
much
faster
and
more
streamlined.
A
We
can,
in
the
future,
ask
people
if
they
propose
a
feature
to
just
implement
it
in
a
standard
Library
way
and
then
standardize
it
in
the
end.
If
it
works
out,
which
will
yeah
have
all
the
advantages
this
one
can
think
about
that,
but
for
user
code
for
the
in
smart
or
contract
code,
the
difference
is
not
that
large,
probably.
A
Definitely
eventually,
I
would
say,
I'm
not
sure
whether
I
mean
getting
the
basic
type
system
going
and
all
that
will
already
take
some
time
but
yeah.
Eventually.
This
is,
of
course,
something
that
will
make
things
easier
to
read,
easier
to
write
and
are
beautiful,
so
and
maybe
not
I
mean
as
long
as
you
don't
want
these
things
to
capture
reliables.
It's
easy
capturing,
even
maybe
something
at
some
point.
We
can
also
consider
but
yeah,
not
not
the
first
thing
we
will
do,
but
eventually.
D
A
E
A
I
mean
so
far
the
Via.
Our
compilation
pipeline
has
not
been
written
with
any
performance
considerations
in
mind
at
all,
if
you've
written
it
for
correctness
first
and
only
now
are
starting
to
realize
how
bad
that
got
and
that
we
need
to
do
something
about
performance
there.
So
I
could
imagine
that
we
can
get
quite
a
way,
but
yeah
it's
hard
to
tell
before
we're
actually
doing
it.
F
A
B
You
were
you
mentioned
that
the
data
location
is
going
to
be
coming
part
of
the
type
instead
of
being
associated
with
the
variable.
Does
that
mean
that
we
are
going
to
be
able
to
start
writing
things
like
an
in-memory
array
of
storage
pointers
or
a
in-storage
array
of
code
data
pointers,
because
those
are
all
well-formed,
but
something
like
a
storage
array
of
call
data
pointers
makes
no
sense
right.
So
what
does
the
well-formedness
look
like?
How
would
that?
How
does
that
sort
of
you
see
that
restricting
that
I.