166 lines
7.1 KiB
ReStructuredText
166 lines
7.1 KiB
ReStructuredText
This page is a follow-up of https://nim-lang.org/araq/destructors.html and further outlines of where Nim is heading in the future. (Did I hear anyone say "Nim v2"?)
|
|
|
|
Nim's strings and sequences should become "GC-free" implementations and are exemplary for how Nim's core should work. Strings and sequences are value-based that means ``=`` performs a copy (conceptually). In practice many copies can be optimized away (see my blog post). The "optimized" copy is called a "move" and is supported via the type bound operator ``=sink``.
|
|
|
|
Rewrite rules (simplified)
|
|
==========================
|
|
|
|
======== ==================== ===========================================================
|
|
Rule Pattern Transformed into
|
|
======== ==================== ===========================================================
|
|
1 var x; stmts var x; try stmts finally: `=destroy`(x)
|
|
2 x = f() `=sink`(x, f())
|
|
3 x = lastReadOf z `=sink`(x, z)
|
|
4 x = y `=`(x, y) # a copy
|
|
5 f(g()) var tmp; `=sink`(tmp, g()); f(tmp); `=destroy`(tmp)
|
|
======== ==================== ===========================================================
|
|
|
|
Rule (5) can be optimized further to ``var tmp = bitwiseCopy(g()); f(tmp); =destroy(tmp)``.
|
|
|
|
|
|
Sink parameters
|
|
===============
|
|
|
|
A ``sink`` parameter conveys a transfer of ownership. The parameter will be *consumed*.
|
|
|
|
A ``sink`` parameter is internally **not** mapped to ``var``, instead the
|
|
usual "pass-by-copy" / "optimize to by-ref if more efficient" implementation
|
|
is used. However, similar rules apply -- you cannot pass a ``const`` to
|
|
a ``sink`` parameter.
|
|
|
|
A ``sink`` parameter **must** be **consumed** exactly once within the
|
|
proc's body. The compiler will use a dataflow analysis to prove this fact.
|
|
For a ``sink`` parameter called ``sp`` a **consume** looks like:
|
|
|
|
.. code-block:: nim
|
|
proc consume(c: var Container; sp: sink T) =
|
|
locationDerivedFrom(c) = sp
|
|
|
|
This assignment is mapped to the ``=sink`` operator.
|
|
|
|
A consume can also be forwarded, "pass sp to a different proc as a sink parameter":
|
|
|
|
.. code-block:: nim
|
|
proc consume(c: var Container; sp: sink T) =
|
|
c.takeAsSink(sp)
|
|
|
|
|
|
Use after consume
|
|
-----------------
|
|
|
|
Locations passed to a ``sink`` parameter are invalidated after the call
|
|
and the compiler tries to prove that it is not used again afterwards. For
|
|
local variables this is quite easy to prove:
|
|
|
|
.. code-block:: nim
|
|
proc consume(c: var Container; element: sink T) =
|
|
c[i] = element
|
|
|
|
proc main() =
|
|
var x = initT()
|
|
for i in 0..3:
|
|
container.consume(x) # Error: attempt to re-use already moved value 'x'
|
|
|
|
For arbitrary locations involving array accesses etc it is too hard to prove
|
|
it is not used afterwards. The compiler transforms ``takeAsSink(sp)`` into
|
|
``takeAsSink(sp); reset(sp)``. ``reset`` sets the value back into its default
|
|
value. For locals the ``reset`` can be optimized away (stores to a dead object),
|
|
for function calls there is no location to reset at all.
|
|
|
|
For a location that has had its value moved into a sink parameter no
|
|
destructor call needs to be injected. This is an important optimization
|
|
to keep the produced code small.
|
|
|
|
|
|
Sink for locals
|
|
---------------
|
|
|
|
``sink T`` is also a valid type for locals. For a variable ``v`` of
|
|
type ``sink T`` no destructor call is injected and it is statically
|
|
ensured that every code path leads to its consumption.
|
|
|
|
|
|
Lent type
|
|
---------
|
|
|
|
``proc p(x: sink T)`` means that the proc ``p`` takes ownership of ``x``.
|
|
To eliminate even more creation/copy <-> destruction pairs, a proc's return
|
|
type can be annotated as ``lent T``. This is useful for "getter" accessors
|
|
that seek to allow an immutable view into a container.
|
|
|
|
Like ``sink T`` ``lent T`` is a valid annotation for local variables too.
|
|
For a variable ``v`` of type ``lent T`` it is statically ensured that no code
|
|
path leads to its consumption, in other words that it must not escape its
|
|
local stack frame (either directly or indirectly via passing to a ``sink``
|
|
parameter). For ``v`` no destructor call is injected since it doesn't own
|
|
the object.
|
|
|
|
The ``sink`` and ``lent`` annotations allow us to remove most (if not all)
|
|
superfluous copies and destructions.
|
|
|
|
``lent T`` is like ``var T`` a hidden pointer that the compiler needs to prove that
|
|
it doesn't outlive its origin.
|
|
|
|
|
|
.. code-block:: nim
|
|
|
|
type
|
|
Tree = object
|
|
kids: seq[Tree]
|
|
|
|
proc construct(kids: sink seq[Tree]): Tree =
|
|
result = Tree(kids: kids)
|
|
# converted into:
|
|
`=sink`(result.kids, kids)
|
|
|
|
proc `[]`*(x: Tree; i: int): lent Tree =
|
|
result = x.kids[i]
|
|
# borrows from 'x', this is transformed into:
|
|
result = addr x.kids[i]
|
|
# This means 'lent' is like 'var T' a hidden pointer.
|
|
# Unlike 'var' this cannot be used to mutate the object.
|
|
|
|
iterator children*(t: Tree): lent Tree =
|
|
for x in t.kids: yield x
|
|
|
|
proc main =
|
|
# everything turned into moves:
|
|
let t = construct(@[construct(@[]), construct(@[])])
|
|
echo t[0] # accessor does not copy the element!
|
|
|
|
|
|
``sink T`` and ``lent T`` introduce further rewrite rules but lead to more efficient code. Even better, these rules optimize away create/copy <-> destroy pairs and so can also make atomic reference counting more efficient by eliminating incref <-> decref pairs.
|
|
|
|
|
|
Rewrite rules (extended)
|
|
========================
|
|
|
|
======== ==================== ===========================================================
|
|
Rule Pattern Transformed into
|
|
======== ==================== ===========================================================
|
|
1.1 var x: T; stmts var x: T; try stmts finally: `=destroy`(x)
|
|
1.2 var x: sink T; stmts var x: sink T; stmts; ensureEmpty(x)
|
|
2 x = f() `=sink`(x, f())
|
|
3 x = lastReadOf z `=sink`(x, z)
|
|
4.1 sinkParam = y `=sink`(sinkParam, y)
|
|
4.2 x = y `=`(x, y) # a copy
|
|
5.1 f_sink(g()) f_sink(g())
|
|
5.2 f_sink(y) f_sink(y); reset(y)
|
|
# 'reset(y)' for locals usually optimized away
|
|
5.3 f_noSink(g()) var tmp = bitwiseCopy(g()); f(tmp); `=destroy`(tmp)
|
|
======== ==================== ===========================================================
|
|
|
|
``sink T`` also affects overloading resolution rules; by the time type checking is performed we have no control flow graph yet so the property ``lastReadOf z`` is not available. However, passing a call expression ``f()`` to a ``g`` taking a sink parameter is a syntactic property and so is available for overloading resolution. Thus I propose the following rule:
|
|
|
|
.. code-block:: nim
|
|
proc add(c: var Container; x: T) # version A
|
|
proc add(c: var Container; x: sink T) # version B
|
|
|
|
var c: Container
|
|
var x: T
|
|
c.add x # calls version A
|
|
c.add f() # calls version B
|
|
# object construction counts as proc call:
|
|
c.add T() # calls version B
|
|
|