added the 'x.p[:T]' notation for explicit generic instantiations in combination with the ddot calling syntax

4 files changed, 41 insertions, 39 deletions

diff --git a/doc/grammar.txt b/doc/grammar.txt
index f25b079f4..e06ebd5d9 100644
--- a/doc/grammar.txt
+++ b/doc/grammar.txt
@@ -26,9 +26,10 @@ symbol = '`' (KEYW|IDENT|literal|(operator|'('|')'|'['|']'|'{'|'}'|'=')+)+ '`'
        | IDENT | KEYW
 exprColonEqExpr = expr (':'|'=' expr)?
 exprList = expr ^+ comma
-dotExpr = expr '.' optInd symbol
-qualifiedIdent = symbol ('.' optInd symbol)?
 exprColonEqExprList = exprColonEqExpr (comma exprColonEqExpr)* (comma)?
+dotExpr = expr '.' optInd (symbol | '[:' exprList ']')
+explicitGenericInstantiation = '[:' exprList ']' ( '(' exprColonEqExpr ')' )?
+qualifiedIdent = symbol ('.' optInd symbol)?
 setOrTableConstr = '{' ((exprColonEqExpr comma)* | ':' ) '}'
 castExpr = 'cast' '[' optInd typeDesc optPar ']' '(' optInd expr optPar ')'
 parKeyw = 'discard' | 'include' | 'if' | 'while' | 'case' | 'try'
diff --git a/doc/manual/generics.txt b/doc/manual/generics.txt
index 4c908fefe..01f76b591 100644
--- a/doc/manual/generics.txt
+++ b/doc/manual/generics.txt
@@ -335,8 +335,8 @@ The concept types can be parametric just like the regular generic types:
     AnyTransform3D* = AnyMatrix[4, 4, float]
 
   proc transposed*(m: AnyMatrix): m.TransposedType =
-    for r in 0 .. <m.R:
-      for c in 0 .. <m.C:
+    for r in 0 ..< m.R:
+      for c in 0 ..< m.C:
         result[r, c] = m[c, r]
 
   proc determinant*(m: AnySquareMatrix): int =
@@ -550,38 +550,38 @@ object inheritance syntax involving the ``of`` keyword:
   proc f(g: BidirectionalGraph) # this one will be preferred if we pass a type
                                 # matching the BidirectionalGraph concept
 
+..
+  Converter type classes
+  ----------------------
 
-Converter type classes
-----------------------
-
-Concepts can also be used to convert a whole range of types to a single type or
-a small set of simpler types. This is achieved with a `return` statement within
-the concept body:
+  Concepts can also be used to convert a whole range of types to a single type or
+  a small set of simpler types. This is achieved with a `return` statement within
+  the concept body:
 
-.. code-block:: nim
-  type
-    Stringable = concept x
-      $x is string
-      return $x
-
-    StringRefValue[CharType] = object
-      base: ptr CharType
-      len: int
-
-    StringRef = concept x
-      # the following would be an overloaded proc for cstring, string, seq and
-      # other user-defined types, returning either a StringRefValue[char] or
-      # StringRefValue[wchar]
-      return makeStringRefValue(x)
-
-  # the varargs param will here be converted to an array of StringRefValues
-  # the proc will have only two instantiations for the two character types
-  proc log(format: static[string], varargs[StringRef])
-
-  # this proc will allow char and wchar values to be mixed in
-  # the same call at the cost of additional instantiations
-  # the varargs param will be converted to a tuple
-  proc log(format: static[string], varargs[distinct StringRef])
+  .. code-block:: nim
+    type
+      Stringable = concept x
+        $x is string
+        return $x
+
+      StringRefValue[CharType] = object
+        base: ptr CharType
+        len: int
+
+      StringRef = concept x
+        # the following would be an overloaded proc for cstring, string, seq and
+        # other user-defined types, returning either a StringRefValue[char] or
+        # StringRefValue[wchar]
+        return makeStringRefValue(x)
+
+    # the varargs param will here be converted to an array of StringRefValues
+    # the proc will have only two instantiations for the two character types
+    proc log(format: static[string], varargs[StringRef])
+
+    # this proc will allow char and wchar values to be mixed in
+    # the same call at the cost of additional instantiations
+    # the varargs param will be converted to a tuple
+    proc log(format: static[string], varargs[distinct StringRef])
 
 
 ..
diff --git a/doc/manual/lexing.txt b/doc/manual/lexing.txt
index 0328ffd55..372de4d56 100644
--- a/doc/manual/lexing.txt
+++ b/doc/manual/lexing.txt
@@ -411,7 +411,7 @@ Other tokens
 
 The following strings denote other tokens::
 
-    `   (     )     {     }     [     ]     ,  ;   [.    .]  {.   .}  (.  .)
+    `   (    )     {    }     [    ]    ,  ;   [.    .]  {.   .}  (.  .)  [:
 
 
 The `slice`:idx: operator `..`:tok: takes precedence over other tokens that
diff --git a/doc/manual/procs.txt b/doc/manual/procs.txt
index 10dd39a52..eb6316e66 100644
--- a/doc/manual/procs.txt
+++ b/doc/manual/procs.txt
@@ -141,13 +141,14 @@ The method call syntax conflicts with explicit generic instantiations:
 ``p[T](x)`` cannot be written as ``x.p[T]`` because ``x.p[T]`` is always
 parsed as ``(x.p)[T]``.
 
-**Future directions**: ``p[.T.]`` might be introduced as an alternative syntax
-to pass explicit types to a generic and then ``x.p[.T.]`` can be parsed as
-``x.(p[.T.])``.
-
 See also: `Limitations of the method call syntax
 <#templates-limitations-of-the-method-call-syntax>`_.
 
+The ``[: ]`` notation has been designed to mitigate this issue: ``x.p[:T]``
+is rewritten by the parser to ``p[T](x)``, ``x.p[:T](y)`` is rewritten to
+``p[T](x, y)``. Note that ``[: ]`` has no AST representation, the rewrite
+is performed directly in the parsing step.
+
 
 Properties
 ----------