Re: Weird behaviour with generic type

2019-07-14 Thread Araq
> What do you think of this solution? I think it's a good solution.

Re: Weird behaviour with generic type

2019-07-13 Thread thenjip
I think it is fine since `TestType`'s members are private. So, constructing a `TestType` from another module would require a call to `newTestType` anyway.

Re: Weird behaviour with generic type

2019-07-13 Thread vitreo12
Thank you all very much for the welcome and for all the help! I know see where the problem is, and I hope that, in the future, an easier syntax would work. In any case, I went with the following solution, using a generic type at the type level and specializing only in the procs' interface:

Re: Weird behaviour with generic type

2019-07-13 Thread mratsim
Welcome to Nim. You are actually touching an advanced part of the Nim type system, the `bind once` versus `bind many` part. **bind once vs bind many** Let's go through that with an example. proc foo1(x, y: SomeInteger) = echo "Ran foo" proc foo2(x: SomeInteger, y: S

Re: Weird behaviour with generic type

2019-07-13 Thread Sixte
> the generic type parameters of newTestType are not distinct They are unified at the type level in `TestType`. The (inferred) type is still `int or string` . Within `newTestType` , terms become available and obviously, type resolution happens at the term level. If this is intended or not might

Re: Weird behaviour with generic type

2019-07-13 Thread gemath
It's actually enough to change just one of the type constraints to make it work: type TestType*[T : AbstractType; Y : distinct AbstractType | AbstractType] = object a : T b : Y Run That's nice, but the fact that the signature of `newTestT

Re: Weird behaviour with generic type

2019-07-13 Thread Sixte
The compiler unifies `T` and `Y`, as long as it finds the same root type, `AbstractType` here. If you write down `AbstractType` again , e.g. using `AbstractType2`, then assigning with `Y`, the program should compile.

Re: Weird behaviour with generic type

2019-07-13 Thread thenjip
Hello, Redefining `TestType` this way allows reusing `AbstractType`, but I find it a little repetitive: type TestType*[T : distinct AbstractType | AbstractType; Y : distinct AbstractType | AbstractType] = object a : T b : Y Run Also, we

Re: Weird behaviour with generic type

2019-07-13 Thread Stefan_Salewski
> coming from Julia. Have missed that statement earlier this morning. So I wonder if you really intent what you are doing? For your TestType, you are not defining one single type, but four distinct different types. So maybe what you want is sum types, called object variants in Nim? For your c

Weird behaviour with generic type

2019-07-12 Thread vitreo12
Hello everyone! I am a new Nim user (and, I have to say, I am pretty excited about this language!) coming from Julia. I was tesing some of Nim's capabilities when coming to generic types and procs, when I ran into this code not compiling: type AbstractType = int or string