Experimental typeImports

[drslump]

Changes the behaviour of from m import T following the discussion at https://github.com/nim-lang/Nim/issues/8013

To be clear, since it's not exactly the same as discussed on the other issue, the behaviour implemented is:

• Automatically include any symbol that references the imported type on its signature

That doesn't include generic types, basically because they are a tad more difficult to implement and I'm not knowledgeable enough to assert if it's something that should be allowed or not regardless of me being able to do the implementation. Comments about this more than welcome :)

[drslump]

Question: shall I avoid using iterators in the compiler code? maybe they are not as efficient as countup loops?

[Araq]

No need to avoid them, they are zero-cost.

[Araq]

I think this example shows that it's not enough the type is the return type of rgb.

[drslump]

sorry, I don't understand, could you rephrase?

Maybe it should demonstrate what's going on more explicitly let pink: Color = rgb(255, 192, 203)?

[Araq]

I mean that rgb should not be imported implicitly as the connection to Color is invisible.

[drslump]

oh, yeah, you're right. I implemented it initially without taking into account the return type but it forced to include the factory function from m import T, initT which I found a pity... and then it occurred to me that one very simple way to teach this is:

Automatically include any symbol that references the imported type on its signature

I think it balances for the implicity on factories, specially since many times it's kind of obvious that they are creating the type.

[Araq]

Yeah, this should be done though. Requires a bit more code, will show you how to do that later.

[timotheecour]

IMO the feature should not work with regular import syntax:
from colors import Color
as a user could genuinely not want a particular method to be imported (even with UFCS)

instead, should be explicit (that way, doens't even have to be "experimental":
from colors import Color.* or, more explicit and flexible in case we want more control later:
import colors: withMethodsmethods(Color)

[Araq]

This feature exists to bring Nim closer to Python and I don't think we should introduce more syntax. And even if we did, the .experimental would remain, new features need to start in the experimental state, no matter how good they seem to be.

[drslump]

Implemented support for generics by using sigmatch.typeRel, it works but I couldn't say if there is any performance implications about the solution, I'm way in over my head to be honest :-)

[Araq]

1. Use the typeRel mechanism for the first parameter only, not for return types or anything else.
2. Yes this means from tables import Table, initTable but this is the better design. The feature exists because you argue it's not obvious where stuff "comes from" and it isn't obvious for rgb.

Otherwise every proc in e.g. regex deals with the Regex type and so import re is the same as from re import Regex. And arguably that's already the case for most modules out there, making this whole feature solve a non-issue, but hey, we already know that.

[drslump]

gotcha, so long, and thanks for all the fish