removing out T from docs since it no longer working (#16378) [backport]

* remove `out T` from docs

see https://github.com/nim-lang/Nim/issues/16131

* remove `out T` in title
* remove entire paragraph
This commit is contained in:
Code Hz 2020-12-18 17:40:43 +08:00 • committed by GitHub
commit 90dbb6f3fb
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -2499,13 +2499,13 @@ matches) is preferred:
gen(ri) # "ref T" gen(ri) # "ref T"
Overloading based on 'var T' / 'out T' Overloading based on 'var T'
-------------------------------------- --------------------------------------
If the formal parameter ``f`` is of type ``var T`` (or ``out T``) If the formal parameter ``f`` is of type ``var T``
in addition to the ordinary in addition to the ordinary type checking,
type checking, the argument is checked to be an `l-value`:idx:. the argument is checked to be an `l-value`:idx:.
``var T`` (or ``out T``) matches better than just ``T`` then. ``var T`` matches better than just ``T`` then.
.. code-block:: nim .. code-block:: nim
proc sayHi(x: int): string = proc sayHi(x: int): string =
@ -2524,17 +2524,6 @@ type checking, the argument is checked to be an `l-value`:idx:.
# 13 # 13
An l-value matches ``var T`` and ``out T`` equally well, hence
the following is ambiguous:
.. code-block:: nim
proc p(x: out string) = x = ""
proc p(x: var string) = x = ""
var v: string
p(v) # ambiguous
Lazy type resolution for untyped Lazy type resolution for untyped
-------------------------------- --------------------------------
@ -4975,7 +4964,7 @@ of "typedesc"-ness is stripped off:
Generic inference restrictions Generic inference restrictions
------------------------------ ------------------------------
The types ``var T``, ``out T`` and ``typedesc[T]`` cannot be inferred in a generic The types ``var T`` and ``typedesc[T]`` cannot be inferred in a generic
instantiation. The following is not allowed: instantiation. The following is not allowed:
.. code-block:: nim .. code-block:: nim
@ -6155,10 +6144,10 @@ noSideEffect pragma
The ``noSideEffect`` pragma is used to mark a proc/iterator to have no side The ``noSideEffect`` pragma is used to mark a proc/iterator to have no side
effects. This means that the proc/iterator only changes locations that are effects. This means that the proc/iterator only changes locations that are
reachable from its parameters and the return value only depends on the reachable from its parameters and the return value only depends on the
arguments. If none of its parameters have the type ``var T`` or ``out T`` arguments. If none of its parameters have the type ``var T`` or ``ref T``
or ``ref T`` or ``ptr T`` this means no locations are modified. It is a static or ``ptr T`` this means no locations are modified. It is a static error to
error to mark a proc/iterator to have no side effect if the compiler cannot mark a proc/iterator to have no side effect if the compiler cannot verify
verify this. this.
As a special semantic rule, the built-in `debugEcho As a special semantic rule, the built-in `debugEcho
<system.html#debugEcho,varargs[typed,]>`_ pretends to be free of side effects, <system.html#debugEcho,varargs[typed,]>`_ pretends to be free of side effects,