Fix word wrapping
This commit is contained in:
Jjp137
parent
e6d5379b3b
commit
3ad48069d3
18 changed files with 146 additions and 125 deletions
|
|
@ -107,12 +107,13 @@ Nim code calling the backend
|
|||
|
||||
Nim code can interface with the backend through the `Foreign function
|
||||
interface <manual.html#foreign-function-interface>`_ mainly through the
|
||||
`importc pragma <manual.html#foreign-function-interface-importc-pragma>`_. The ``importc`` pragma is the
|
||||
*generic* way of making backend symbols available in Nim and is available
|
||||
in all the target backends (JavaScript too). The C++ or Objective-C backends
|
||||
have their respective `ImportCpp <manual.html#implementation-specific-pragmas-importcpp-pragma>`_ and
|
||||
`ImportObjC <manual.html#implementation-specific-pragmas-importobjc-pragma>`_ pragmas to call methods from
|
||||
classes.
|
||||
`importc pragma <manual.html#foreign-function-interface-importc-pragma>`_.
|
||||
The ``importc`` pragma is the *generic* way of making backend symbols available
|
||||
in Nim and is available in all the target backends (JavaScript too). The C++
|
||||
or Objective-C backends have their respective `ImportCpp
|
||||
<manual.html#implementation-specific-pragmas-importcpp-pragma>`_ and
|
||||
`ImportObjC <manual.html#implementation-specific-pragmas-importobjc-pragma>`_
|
||||
pragmas to call methods from classes.
|
||||
|
||||
Whenever you use any of these pragmas you need to integrate native code into
|
||||
your final binary. In the case of JavaScript this is no problem at all, the
|
||||
|
|
@ -124,16 +125,16 @@ statically or dynamically. The preferred way of integrating native code is to
|
|||
use dynamic linking because it allows you to compile Nim programs without
|
||||
the need for having the related development libraries installed. This is done
|
||||
through the `dynlib pragma for import
|
||||
<manual.html#foreign-function-interface-dynlib-pragma-for-import>`_, though more specific control can be
|
||||
gained using the `dynlib module <dynlib.html>`_.
|
||||
<manual.html#foreign-function-interface-dynlib-pragma-for-import>`_, though
|
||||
more specific control can be gained using the `dynlib module <dynlib.html>`_.
|
||||
|
||||
The `dynlibOverride <nimc.html#dynliboverride>`_ command line switch allows
|
||||
to avoid dynamic linking if you need to statically link something instead.
|
||||
Nim wrappers designed to statically link source files can use the `compile
|
||||
pragma <manual.html#implementation-specific-pragmas-compile-pragma>`_ if there are few sources or providing
|
||||
them along the Nim code is easier than using a system library. Libraries
|
||||
installed on the host system can be linked in with the `PassL pragma
|
||||
<manual.html#implementation-specific-pragmas-passl-pragma>`_.
|
||||
pragma <manual.html#implementation-specific-pragmas-compile-pragma>`_ if
|
||||
there are few sources or providing them along the Nim code is easier than using
|
||||
a system library. Libraries installed on the host system can be linked in with
|
||||
the `PassL pragma <manual.html#implementation-specific-pragmas-passl-pragma>`_.
|
||||
|
||||
To wrap native code, take a look at the `c2nim tool <https://nim-lang.org/docs/c2nim.html>`_ which helps
|
||||
with the process of scanning and transforming header files into a Nim
|
||||
|
|
@ -215,12 +216,12 @@ Backend code calling Nim
|
|||
------------------------
|
||||
|
||||
Backend code can interface with Nim code exposed through the `exportc
|
||||
pragma <manual.html#foreign-function-interface-exportc-pragma>`_. The ``exportc`` pragma is the *generic*
|
||||
way of making Nim symbols available to the backends. By default the Nim
|
||||
compiler will mangle all the Nim symbols to avoid any name collision, so
|
||||
the most significant thing the ``exportc`` pragma does is maintain the Nim
|
||||
symbol name, or if specified, use an alternative symbol for the backend in
|
||||
case the symbol rules don't match.
|
||||
pragma <manual.html#foreign-function-interface-exportc-pragma>`_. The
|
||||
``exportc`` pragma is the *generic* way of making Nim symbols available to
|
||||
the backends. By default the Nim compiler will mangle all the Nim symbols to
|
||||
avoid any name collision, so the most significant thing the ``exportc`` pragma
|
||||
does is maintain the Nim symbol name, or if specified, use an alternative
|
||||
symbol for the backend in case the symbol rules don't match.
|
||||
|
||||
The JavaScript target doesn't have any further interfacing considerations
|
||||
since it also has garbage collection, but the C targets require you to
|
||||
|
|
@ -329,8 +330,8 @@ Nimcache naming logic
|
|||
The `nimcache`:idx: directory is generated during compilation and will hold
|
||||
either temporary or final files depending on your backend target. The default
|
||||
name for the directory depends on the used backend and on your OS but you can
|
||||
use the ``--nimcache`` `compiler switch <nimc.html#compiler-usage-command-line-switches>`_ to
|
||||
change it.
|
||||
use the ``--nimcache`` `compiler switch
|
||||
<nimc.html#compiler-usage-command-line-switches>`_ to change it.
|
||||
|
||||
|
||||
Memory management
|
||||
|
|
@ -384,8 +385,8 @@ the backend will need careful consideration of who controls who. If you want
|
|||
to hand a Nim reference to C code, you will need to use `GC_ref
|
||||
<system.html#GC_ref,ref.T>`_ to mark the reference as used, so it does not get
|
||||
freed. And for the C backend you will need to expose the `GC_unref
|
||||
<system.html#GC_unref,ref.T>`_ proc to clean up this memory when it is not required
|
||||
any more.
|
||||
<system.html#GC_unref,ref.T>`_ proc to clean up this memory when it is not
|
||||
required any more.
|
||||
|
||||
Again, if you are wrapping a library which *mallocs* and *frees* data
|
||||
structures, you need to expose the appropriate *free* function to Nim so
|
||||
|
|
|
|||
|
|
@ -213,8 +213,7 @@ as well as ``testament`` and guarantee they stay in sync.
|
|||
assert "baz".addBar == "bazBar"
|
||||
result = a & "Bar"
|
||||
|
||||
See `parentDir <os.html#parentDir,string>`_
|
||||
example.
|
||||
See `parentDir <os.html#parentDir,string>`_ example.
|
||||
|
||||
The RestructuredText Nim uses has a special syntax for including code snippets
|
||||
embedded in documentation; these are not run by ``nim doc`` and therefore are
|
||||
|
|
|
|||
|
|
@ -307,7 +307,8 @@ symbols in the `system module <system.html>`_.
|
|||
`#len,seq[T] <system.html#len,seq[T]>`_
|
||||
* ``iterator pairs[T](a: seq[T]): tuple[key: int, val: T] {.inline.}`` **=>**
|
||||
`#pairs.i,seq[T] <system.html#pairs.i,seq[T]>`_
|
||||
* ``template newException[](exceptn: typedesc; message: string; parentException: ref Exception = nil): untyped`` **=>**
|
||||
* ``template newException[](exceptn: typedesc; message: string;
|
||||
parentException: ref Exception = nil): untyped`` **=>**
|
||||
`#newException.t,typedesc,string,ref.Exception
|
||||
<system.html#newException.t,typedesc,string,ref.Exception>`_
|
||||
|
||||
|
|
@ -316,14 +317,15 @@ Index (idx) file format
|
|||
=======================
|
||||
|
||||
Files with the ``.idx`` extension are generated when you use the `Index
|
||||
switch <#related-options-index-switch>`_ along with commands to generate documentation from source or text
|
||||
files. You can programatically generate indices with the `setIndexTerm()
|
||||
<rstgen.html#setIndexTerm,RstGenerator,string,string,string,string,string>`_ and `writeIndexFile()
|
||||
<rstgen.html#writeIndexFile,RstGenerator,string>`_ procs. The purpose of ``idx`` files is to hold
|
||||
the interesting symbols and their HTML references so they can be later
|
||||
concatenated into a big index file with `mergeIndexes()
|
||||
<rstgen.html#mergeIndexes,string>`_. This section documents the file format in
|
||||
detail.
|
||||
switch <#related-options-index-switch>`_ along with commands to generate
|
||||
documentation from source or text files. You can programatically generate
|
||||
indices with the `setIndexTerm()
|
||||
<rstgen.html#setIndexTerm,RstGenerator,string,string,string,string,string>`_
|
||||
and `writeIndexFile() <rstgen.html#writeIndexFile,RstGenerator,string>`_ procs.
|
||||
The purpose of ``idx`` files is to hold the interesting symbols and their HTML
|
||||
references so they can be later concatenated into a big index file with
|
||||
`mergeIndexes() <rstgen.html#mergeIndexes,string>`_. This section documents
|
||||
the file format in detail.
|
||||
|
||||
Index files are line oriented and tab separated (newline and tab characters
|
||||
have to be escaped). Each line represents a record with at least two fields,
|
||||
|
|
|
|||
|
|
@ -164,7 +164,8 @@ you can pass ``--gc:`` on the compile command with the choosed garbage collector
|
|||
|
||||
The same Nim code can be compiled to use any of the garbage collectors;
|
||||
the Nim syntax generally will not change from one garbage collector to another.
|
||||
No garbage collector is used for `JavaScript and NodeJS <backends.html#backends-the-javascript-target>`_ compilation targets.
|
||||
No garbage collector is used for `JavaScript and NodeJS
|
||||
<backends.html#backends-the-javascript-target>`_ compilation targets.
|
||||
`NimScript <nims.html>`_ target uses Nim VM garbage collector.
|
||||
|
||||
If you are new to Nim and just starting, the default garbage collector is balanced to fit most common use cases.
|
||||
|
|
|
|||
|
|
@ -124,9 +124,9 @@ separators!).
|
|||
|
||||
The typical usage scenario for this option is to call it after the
|
||||
user has typed the dot character for `the object oriented call
|
||||
syntax <tut2.html#object-oriented-programming-method-call-syntax>`_. Idetools will try to return
|
||||
the suggestions sorted first by scope (from innermost to outermost)
|
||||
and then by item name.
|
||||
syntax <tut2.html#object-oriented-programming-method-call-syntax>`_.
|
||||
Idetools will try to return the suggestions sorted first by scope
|
||||
(from innermost to outermost) and then by item name.
|
||||
|
||||
|
||||
Invocation context
|
||||
|
|
@ -359,7 +359,8 @@ defined, since at that point in the file the parser hasn't processed
|
|||
the full line yet. The signature will be returned complete in
|
||||
posterior instances of the method.
|
||||
|
||||
Methods imply `dynamic dispatch <tut2.html#object-oriented-programming-dynamic-dispatch>`_ and
|
||||
Methods imply `dynamic dispatch
|
||||
<tut2.html#object-oriented-programming-dynamic-dispatch>`_ and
|
||||
idetools performs a static analysis on the code. For this reason
|
||||
idetools may not return the definition of the correct method you
|
||||
are querying because it may be impossible to know until the code
|
||||
|
|
|
|||
|
|
@ -47,7 +47,8 @@ csource command
|
|||
---------------
|
||||
|
||||
The `csource`:idx: command builds the C sources for installation. It accepts
|
||||
the same options as you would pass to the `boot command <#commands-boot-command>`_.
|
||||
the same options as you would pass to the `boot command
|
||||
<#commands-boot-command>`_.
|
||||
|
||||
temp command
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -1482,7 +1482,8 @@ order. The *names* of the fields also have to be identical.
|
|||
|
||||
The assignment operator for tuples copies each component.
|
||||
The default assignment operator for objects copies each component. Overloading
|
||||
of the assignment operator is described `here <manual_experimental.html#type-bound-operations>`_.
|
||||
of the assignment operator is described `here
|
||||
<manual_experimental.html#type-bound-operations>`_.
|
||||
|
||||
.. code-block:: nim
|
||||
|
||||
|
|
@ -3484,8 +3485,8 @@ more argument in this case:
|
|||
assert x == y
|
||||
|
||||
The command invocation syntax also can't have complex expressions as arguments.
|
||||
For example: (`anonymous procs <#procedures-anonymous-procs>`_), ``if``, ``case`` or ``try``.
|
||||
Function calls with no arguments still needs () to
|
||||
For example: (`anonymous procs <#procedures-anonymous-procs>`_), ``if``,
|
||||
``case`` or ``try``. Function calls with no arguments still needs () to
|
||||
distinguish between a call and the function itself as a first class value.
|
||||
|
||||
|
||||
|
|
@ -3505,8 +3506,8 @@ Creating closures in loops
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Since closures capture local variables by reference it is often not wanted
|
||||
behavior inside loop bodies. See `closureScope <system.html#closureScope.t,untyped>`_
|
||||
for details on how to change this behavior.
|
||||
behavior inside loop bodies. See `closureScope
|
||||
<system.html#closureScope.t,untyped>`_ for details on how to change this behavior.
|
||||
|
||||
Anonymous Procs
|
||||
---------------
|
||||
|
|
@ -5895,9 +5896,9 @@ or ``ref T`` or ``ptr T`` this means no locations are modified. It is a static
|
|||
error to mark a proc/iterator to have no side effect if the compiler cannot
|
||||
verify this.
|
||||
|
||||
As a special semantic rule, the built-in `debugEcho <system.html#debugEcho,varargs[typed,]>`_
|
||||
pretends to be free of side effects, so that it can be used for debugging
|
||||
routines marked as ``noSideEffect``.
|
||||
As a special semantic rule, the built-in `debugEcho
|
||||
<system.html#debugEcho,varargs[typed,]>`_ pretends to be free of side effects,
|
||||
so that it can be used for debugging routines marked as ``noSideEffect``.
|
||||
|
||||
``func`` is syntactic sugar for a proc with no side effects:
|
||||
|
||||
|
|
|
|||
|
|
@ -203,9 +203,10 @@ useful only when interfacing with imported types having such semantics.
|
|||
Automatic dereferencing
|
||||
=======================
|
||||
|
||||
If the `experimental mode <manual.html#pragmas-experimental-pragma>`_ is active and no other match
|
||||
is found, the first argument ``a`` is dereferenced automatically if it's a
|
||||
pointer type and overloading resolution is tried with ``a[]`` instead.
|
||||
If the `experimental mode <manual.html#pragmas-experimental-pragma>`_ is active
|
||||
and no other match is found, the first argument ``a`` is dereferenced
|
||||
automatically if it's a pointer type and overloading resolution is tried
|
||||
with ``a[]`` instead.
|
||||
|
||||
|
||||
Automatic self insertions
|
||||
|
|
|
|||
10
doc/nimc.rst
10
doc/nimc.rst
|
|
@ -114,7 +114,8 @@ Level Description
|
|||
===== ============================================
|
||||
0 Minimal output level for the compiler.
|
||||
1 Displays compilation of all the compiled files, including those imported
|
||||
by other modules or through the `compile pragma<manual.html#implementation-specific-pragmas-compile-pragma>`_.
|
||||
by other modules or through the `compile pragma
|
||||
<manual.html#implementation-specific-pragmas-compile-pragma>`_.
|
||||
This is the default level.
|
||||
2 Displays compilation statistics, enumerates the dynamic
|
||||
libraries that will be loaded by the final binary and dumps to
|
||||
|
|
@ -130,9 +131,10 @@ Compile time symbols
|
|||
|
||||
Through the ``-d:x`` or ``--define:x`` switch you can define compile time
|
||||
symbols for conditional compilation. The defined switches can be checked in
|
||||
source code with the `when statement <manual.html#statements-and-expressions-when-statement>`_ and
|
||||
`defined proc <system.html#defined,untyped>`_. The typical use of this switch is to
|
||||
enable builds in release mode (``-d:release``) where optimizations are
|
||||
source code with the `when statement
|
||||
<manual.html#statements-and-expressions-when-statement>`_ and
|
||||
`defined proc <system.html#defined,untyped>`_. The typical use of this switch is
|
||||
to enable builds in release mode (``-d:release``) where optimizations are
|
||||
enabled for better performance. Another common use is the ``-d:ssl`` switch to
|
||||
activate SSL sockets.
|
||||
|
||||
|
|
|
|||
|
|
@ -105,9 +105,9 @@ completion symbols at some point in the file.
|
|||
|
||||
The typical usage scenario for this option is to call it after the
|
||||
user has typed the dot character for `the object oriented call
|
||||
syntax <tut2.html#object-oriented-programming-method-call-syntax>`_. Nimsuggest will try to return
|
||||
the suggestions sorted first by scope (from innermost to outermost)
|
||||
and then by item name.
|
||||
syntax <tut2.html#object-oriented-programming-method-call-syntax>`_.
|
||||
Nimsuggest will try to return the suggestions sorted first by scope
|
||||
(from innermost to outermost) and then by item name.
|
||||
|
||||
|
||||
Invocation context
|
||||
|
|
|
|||
62
doc/tut1.rst
62
doc/tut1.rst
|
|
@ -326,10 +326,11 @@ the compiler that for every other value nothing should be done:
|
|||
of 3, 8: echo "The number is 3 or 8"
|
||||
else: discard
|
||||
|
||||
The empty `discard statement <#procedures-discard-statement>`_ is a *do nothing* statement. The compiler knows
|
||||
that a case statement with an else part cannot fail and thus the error
|
||||
disappears. Note that it is impossible to cover all possible string values:
|
||||
that is why string cases always need an ``else`` branch.
|
||||
The empty `discard statement <#procedures-discard-statement>`_ is a *do
|
||||
nothing* statement. The compiler knows that a case statement with an else part
|
||||
cannot fail and thus the error disappears. Note that it is impossible to cover
|
||||
all possible string values: that is why string cases always need an ``else``
|
||||
branch.
|
||||
|
||||
In general the case statement is used for subrange types or enumerations where
|
||||
it is of great help that the compiler checks that you covered any possible
|
||||
|
|
@ -359,8 +360,8 @@ For statement
|
|||
-------------
|
||||
|
||||
The ``for`` statement is a construct to loop over any element an *iterator*
|
||||
provides. The example uses the built-in `countup <system.html#countup.i,T,T,Positive>`_
|
||||
iterator:
|
||||
provides. The example uses the built-in `countup
|
||||
<system.html#countup.i,T,T,Positive>`_ iterator:
|
||||
|
||||
.. code-block:: nim
|
||||
:test: "nim c $1"
|
||||
|
|
@ -371,8 +372,8 @@ iterator:
|
|||
|
||||
The variable ``i`` is implicitly declared by the
|
||||
``for`` loop and has the type ``int``, because that is what `countup
|
||||
<system.html#countup.i,T,T,Positive>`_ returns. ``i`` runs through the values 1, 2, .., 10.
|
||||
Each value is ``echo``-ed. This code does the same:
|
||||
<system.html#countup.i,T,T,Positive>`_ returns. ``i`` runs through the values
|
||||
1, 2, .., 10. Each value is ``echo``-ed. This code does the same:
|
||||
|
||||
.. code-block:: nim
|
||||
echo "Counting to 10: "
|
||||
|
|
@ -570,10 +571,10 @@ an expression is allowed:
|
|||
Procedures
|
||||
==========
|
||||
|
||||
To define new commands like `echo <system.html#echo,varargs[typed,]>`_ and `readLine
|
||||
<io.html#readLine,File>`_ in the examples, the concept of a `procedure`
|
||||
is needed. (Some languages call them *methods* or *functions*.) In Nim new
|
||||
procedures are defined with the ``proc`` keyword:
|
||||
To define new commands like `echo <system.html#echo,varargs[typed,]>`_
|
||||
and `readLine <io.html#readLine,File>`_ in the examples, the concept of a
|
||||
`procedure` is needed. (Some languages call them *methods* or *functions*.)
|
||||
In Nim new procedures are defined with the ``proc`` keyword:
|
||||
|
||||
.. code-block:: nim
|
||||
:test: "nim c $1"
|
||||
|
|
@ -845,8 +846,8 @@ Let's return to the simple counting example:
|
|||
for i in countup(1, 10):
|
||||
echo i
|
||||
|
||||
Can a `countup <system.html#countup.i,T,T,Positive>`_ proc be written that supports this
|
||||
loop? Lets try:
|
||||
Can a `countup <system.html#countup.i,T,T,Positive>`_ proc be written that
|
||||
supports this loop? Lets try:
|
||||
|
||||
.. code-block:: nim
|
||||
proc countup(a, b: int): int =
|
||||
|
|
@ -1010,8 +1011,8 @@ floats and follow the IEEE-754 standard.
|
|||
Automatic type conversion in expressions with different kinds of floating
|
||||
point types is performed: the smaller type is converted to the larger. Integer
|
||||
types are **not** converted to floating point types automatically, nor vice
|
||||
versa. Use the `toInt <system.html#toInt,float>`_ and `toFloat <system.html#toFloat,int>`_
|
||||
procs for these conversions.
|
||||
versa. Use the `toInt <system.html#toInt,float>`_ and
|
||||
`toFloat <system.html#toFloat,int>`_ procs for these conversions.
|
||||
|
||||
|
||||
Type Conversion
|
||||
|
|
@ -1128,8 +1129,8 @@ Operation Comment
|
|||
----------------- --------------------------------------------------------
|
||||
|
||||
The `inc <system.html#inc,T,int>`_, `dec <system.html#dec,T,int>`_, `succ
|
||||
<system.html#succ,T,int>`_ and `pred <system.html#pred,T,int>`_ operations can fail by
|
||||
raising an `EOutOfRange` or `EOverflow` exception. (If the code has been
|
||||
<system.html#succ,T,int>`_ and `pred <system.html#pred,T,int>`_ operations can
|
||||
fail by raising an `EOutOfRange` or `EOverflow` exception. (If the code has been
|
||||
compiled with the proper runtime checks turned on.)
|
||||
|
||||
|
||||
|
|
@ -1150,8 +1151,8 @@ compile-time or runtime error. Assignments from the base type to one of its
|
|||
subrange types (and vice versa) are allowed.
|
||||
|
||||
The ``system`` module defines the important `Natural <system.html#Natural>`_
|
||||
type as ``range[0..high(int)]`` (`high <system.html#high,typedesc[T]>`_ returns the
|
||||
maximal value). Other programming languages may suggest the use of unsigned
|
||||
type as ``range[0..high(int)]`` (`high <system.html#high,typedesc[T]>`_ returns
|
||||
the maximal value). Other programming languages may suggest the use of unsigned
|
||||
integers for natural numbers. This is often **unwise**: you don't want unsigned
|
||||
arithmetic (which wraps around) just because the numbers cannot be negative.
|
||||
Nim's ``Natural`` type helps to avoid this common programming error.
|
||||
|
|
@ -1189,8 +1190,9 @@ Arrays are value types, like any other Nim type. The assignment operator
|
|||
copies the whole array contents.
|
||||
|
||||
The built-in `len <system.html#len,TOpenArray>`_ proc returns the array's
|
||||
length. `low(a) <system.html#low,openArray[T]>`_ returns the lowest valid index for the
|
||||
array `a` and `high(a) <system.html#high,openArray[T]>`_ the highest valid index.
|
||||
length. `low(a) <system.html#low,openArray[T]>`_ returns the lowest valid index
|
||||
for the array `a` and `high(a) <system.html#high,openArray[T]>`_ the highest
|
||||
valid index.
|
||||
|
||||
.. code-block:: nim
|
||||
:test: "nim c $1"
|
||||
|
|
@ -1266,8 +1268,8 @@ allocated on the heap and garbage collected.
|
|||
|
||||
Sequences are always indexed with an ``int`` starting at position 0. The `len
|
||||
<system.html#len,seq[T]>`_, `low <system.html#low,openArray[T]>`_ and `high
|
||||
<system.html#high,openArray[T]>`_ operations are available for sequences too. The notation
|
||||
``x[i]`` can be used to access the i-th element of ``x``.
|
||||
<system.html#high,openArray[T]>`_ operations are available for sequences too.
|
||||
The notation ``x[i]`` can be used to access the i-th element of ``x``.
|
||||
|
||||
Sequences can be constructed by the array constructor ``[]`` in conjunction
|
||||
with the array to sequence operator ``@``. Another way to allocate space for
|
||||
|
|
@ -1318,10 +1320,10 @@ Open arrays
|
|||
Often fixed size arrays turn out to be too inflexible; procedures should be
|
||||
able to deal with arrays of different sizes. The `openarray`:idx: type allows
|
||||
this. Openarrays are always indexed with an ``int`` starting at position 0.
|
||||
The `len <system.html#len,TOpenArray>`_, `low <system.html#low,openArray[T]>`_ and `high
|
||||
<system.html#high,openArray[T]>`_ operations are available for open arrays too. Any array
|
||||
with a compatible base type can be passed to an openarray parameter, the index
|
||||
type does not matter.
|
||||
The `len <system.html#len,TOpenArray>`_, `low <system.html#low,openArray[T]>`_
|
||||
and `high <system.html#high,openArray[T]>`_ operations are available for open
|
||||
arrays too. Any array with a compatible base type can be passed to an
|
||||
openarray parameter, the index type does not matter.
|
||||
|
||||
.. code-block:: nim
|
||||
:test: "nim c $1"
|
||||
|
|
@ -1561,8 +1563,8 @@ having the same field types.
|
|||
|
||||
Tuples can be *unpacked* during variable assignment (and only then!). This can
|
||||
be handy to assign directly the fields of the tuples to individually named
|
||||
variables. An example of this is the `splitFile <os.html#splitFile,string>`_ proc
|
||||
from the `os module <os.html>`_ which returns the directory, name and
|
||||
variables. An example of this is the `splitFile <os.html#splitFile,string>`_
|
||||
proc from the `os module <os.html>`_ which returns the directory, name and
|
||||
extension of a path at the same time. For tuple unpacking to work you must
|
||||
use parentheses around the values you want to assign the unpacking to,
|
||||
otherwise you will be assigning the same value to all the individual
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue