Method dispatch silently breaks on non-ref objects

[mcclure]

Following is with Nim built from git:07d7d35d995262830

Consider this code:

type
    A = object of RootObj
    B = object of A

method identify(a:A) {.base.} = echo "A"
method identify(b:B) = echo "B"

var b: B
var a: A = b

identify(b)
identify(a)

Observed behavior: This program prints

B
A

There are no warnings or errors, even on verbosity:2.

It appears that when I say "var a: A = b" I am implicitly converting b to A type and therefore the b identity is lost. If B has fields, it appears those fields are getting thrown away. There is no text indicating this loss of identity in the manual either under http://nim-lang.org/docs/manual.html#types-tuples-and-object-types or http://nim-lang.org/docs/manual.html#multi-methods (the former section says "the default assignment operator for objects copies each component" but it is far from obvious this text implies "...and subclass-related are thrown away"). The behavior appears to be in active conflict with the "convertible relations" section http://nim-lang.org/docs/manual.html#type-relations-convertible-relation which say A and B should be explicitly convertible because B is a subtype but do not say they are implicitly convertible.

Expected behavior:

1. One or more of the following should be true:
   1. Naively, my expectation is that if I copy b:B to a:A, the value referred to by a should still be a B, act like a B, have all of B's fields etc. This is how ref types work and therefore this is how the examples in the Nim manual work, and this is how my intuition works of objects in an object-oriented language. Therefore the above program should print B\nB. However, given how I understand the Nim memory model to work, I expect this is probably not possible for non-ref objects. (C++ for example would not support this for stack objects.)
   2. If the language's actual behavior cannot match my naive intuition, the language should provide an error or warning when I copy objects between vars in a way which will non-intuitively change their behavior. This would be consistent with other behavior in Nim already. For example, in Nim, I cannot copy a int value to a float var or vice versa without a cast. Copying between vars of non-ref type A and B of A involves a loss of information or at least a change analogous to copying between ints and floats, therefore copying between a:A and b:B where A and B are non-ref objects should require an explicit cast. Again, this behavior (error on direct assignment from B of A to A without cast) seems to be required by the "convertible relation" section of the manual.
   3. Because Nim is usually aggressive about giving warnings when I am doing something that looks like a mistake (variable named l, etc) Nim should give me a warning for the above code that method is useless and I should use proc instead. In general, any pair of methods could just as well be procs unless at least one argument dispatches on a ref object. Any use of method where the special dispatch capabilities of method are not being used therefore is probably accidental on the part of the user and a warning is appropriate.
2. No matter what, the manual should unambiguously state that assigning an object of non-ref type B to non-ref var A will convert it to an A, and thus polymorphism/"method" are effectively exclusive to ref objects. In addition, the "convertible relation" section should accurately describe under what conditions objects are implicitly converted.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you think it is still a valid issue, write a comment below; otherwise it will be closed. Thank you for your contributions.

[ringabout]

Since Nim v 0.19.0, this will give error:

C:\Users\blue\.choosenim\toolchains\nim-#devel\lib\system\assign.nim(139) genericAssign
C:\Users\blue\.choosenim\toolchains\nim-#devel\lib\system\assign.nim(125) genericAssignAux
C:\Users\blue\.choosenim\toolchains\nim-#devel\lib\system\fatal.nim(49) sysFatal
Error: unhandled exception: invalid object assignment [ObjectAssignmentDefect]
Error: execution of an external program failed: 'D:\QQPCmgr\Desktop\Nim\test.exe '