UFCS type conversion conflicts with dot operator

[n0bra1n3r]

I get an error when using the dot operator with an identifier that is the same as a type's name in the current scope. I'm not sure if this is intended behavior or a bug. I know the "dotOperators" feature is still experimental, but just wanted to report this in case there were any plans of making it not experimental.

Example

{.experimental:"dotOperators".}

type Test = object

template `.`(obj: int, field: untyped) =
  static: echo "ACCESS " & astToStr(field)
  
var a: int

a.stuff # works
a.Test # ERROR

Current Output

ACCESS stuff
Error: type mismatch: got <int> but expected 'Test = object'

Expected Output

ACCESS stuff
ACCESS Test

Possible Solution

Unknown

Additional Information

None

$ nim -v
Nim Compiler Version 1.5.1 [Windows: amd64]

[n0bra1n3r]

I just wanted to expand on the above that the dot operator doesn't conflict with procs. I was hoping the behavior would be the same with types:

{.experimental:"dotOperators".}

type Test = object

proc Test2(a: float) =
  echo "UFCS Test2"

template `.`(obj: int, field: untyped) =
  static: echo "ACCESS " & astToStr(field)
  
var a: int
var b: float
  
a.stuff # works
a.Test2 # works: calls dot operator and not the proc `Test2`
b.Test2 # works: calls the proc `Test2` and not the dot operator
a.Test # type mismatch: got <int> but expected 'Test = object'

[metagn]

I think whether or not this should be changed, the behavior should be consistent with proc Test2. I think we could use something like pre-existing {.immediate.} to allow both Test and Test2 to be counted, otherwise neither would be counted, but I would like to know what people who use dot operators think.

[n0bra1n3r]

It would be great if the behavior was the same as with proc Test2. I use dotOperators heavily to interop with several C++ libraries for my game engine, and the current behavior requires me to name (or import except) my types so they don't interfere with C++ field access. As far as I'm concerned dotOperators is a dream-come-true, as I don't know any other compiled language that allows such easy interop with C++ (far superior even to D). It would be perfect if the behavior with types was the same as with procs.

[Araq]

As far as I'm concerned dotOperators is a dream-come-true, as I don't know any other compiled language that allows such easy interop with C++ (far superior even to D). It would be perfect if the behavior with types was the same as with procs.

Thanks for the valuable feedback as I was about to deprecate dot operators, cough. Will reconsider my opinion.