Let's go through your examples now.
type StrangeConcept[T] = concept c
c is T # Equivalent to "c is any", which is true
float(c) is T # Equivalent to "float(c) is any", which is true
$c is T # Equivalent to "$c is any", which is true
when int is StrangeConcept:
echo "Yes, it is" # this is printed
Nope, it should be:
type StrangeConcept = concept c
c is type(c) # Equivalent to "c is any", which is true
float(c) is type(c) # Equivalent to "float(c) is any", which is true
$c is type(c) # Equivalent to "$c is any", which is true
No container, hence no `T`. As a workaround you need to write `type(c)`. A
clean solution IMO.
type NewConcept[T] = concept c
c is seq[T]
...
Works.
type YouCanAddOne[T] = concept c
c is T
c+1 is T
Doesn't work this way, numbers are not containers. `type(c)` is the workaround.
type MixWithFunctions1[T] = concept c
f[T](c)
...
type MixWithFunctions2[T] = concept c
f(c, (new T)[])
...
Maybe this implies the inference rules need to cover `proc (S, ...): T` too? Oh
well, you can extend them. But I don't think this needs to be supported for
version 1 of the concepts implementation.
