diff options
author | Araq <rumpf_a@web.de> | 2014-03-10 22:23:38 +0100 |
---|---|---|
committer | Araq <rumpf_a@web.de> | 2014-03-10 22:23:38 +0100 |
commit | 3270676e77676335446287fcff05aa6a6b9b4919 (patch) | |
tree | 4bd724bed5ae887efa9d8f97494755715980ca20 /doc/manual.txt | |
parent | 121553d1a69c4d175259944f6bdc9f9dcfda9cdd (diff) | |
parent | 1546d210c5739213ebf93eb0cb624ca7a9fe9ad6 (diff) | |
download | Nim-3270676e77676335446287fcff05aa6a6b9b4919.tar.gz |
Merge branch 'devel' of https://github.com/Araq/Nimrod into devel
Diffstat (limited to 'doc/manual.txt')
-rw-r--r-- | doc/manual.txt | 24 |
1 files changed, 15 insertions, 9 deletions
diff --git a/doc/manual.txt b/doc/manual.txt index 04c69cf94..ab1badaf3 100644 --- a/doc/manual.txt +++ b/doc/manual.txt @@ -2875,7 +2875,6 @@ as there are components in the tuple. The i'th iteration variable's type is the type of the i'th component. In other words, implicit tuple unpacking in a for loop context is supported. - Implict items/pairs invocations ------------------------------- @@ -2900,10 +2899,11 @@ First class iterators There are 2 kinds of iterators in Nimrod: *inline* and *closure* iterators. An `inline iterator`:idx: is an iterator that's always inlined by the compiler leading to zero overhead for the abstraction, but may result in a heavy -increase in code size. Inline iterators are second class -citizens; one cannot pass them around like first class procs. +increase in code size. Inline iterators are second class citizens; +They can be passed as parameters only to other inlining code facilities like +templates, macros and other inline iterators. -In contrast to that, a `closure iterator`:idx: can be passed around: +In contrast to that, a `closure iterator`:idx: can be passed around more freely: .. code-block:: nimrod iterator count0(): int {.closure.} = @@ -2926,9 +2926,7 @@ Closure iterators have other restrictions than inline iterators: 1. ``yield`` in a closure iterator can not occur in a ``try`` statement. 2. For now, a closure iterator cannot be evaluated at compile time. 3. ``return`` is allowed in a closure iterator (but rarely useful). -4. Since closure iterators can be used as a collaborative tasking - system, ``void`` is a valid return type for them. -5. Both inline and closure iterators cannot be recursive. +4. Both inline and closure iterators cannot be recursive. Iterators that are neither marked ``{.closure.}`` nor ``{.inline.}`` explicitly default to being inline, but that this may change in future versions of the @@ -2990,6 +2988,14 @@ parameters of an outer factory proc: for f in foo(): echo f +Implicit return type +-------------------- + +Since inline interators must always produce values that will be consumed in +a for loop, the compiler will implicity use the ``auto`` return type if no +type is given by the user. In contrast, since closure iterators can be used +as a collaborative tasking system, ``void`` is a valid return type for them. + Type sections ============= @@ -4069,8 +4075,8 @@ Static params can also appear in the signatures of generic types: AffineTransform2D[T] = Matrix[3, 3, T] AffineTransform3D[T] = Matrix[4, 4, T] - AffineTransform3D[float] # OK - AffineTransform2D[string] # Error, `string` is not a `Number` + var m1: AffineTransform3D[float] # OK + var m2: AffineTransform2D[string] # Error, `string` is not a `Number` typedesc |