Opinions for exporting common names

[rfourquet]

@DrChainsaw

Sorry for not letting this go, but I feel the dilemma is that using Foo would still be perfectly possible if only one just did not export e.g. name . E.g. typing using Foo followed by using Foo: name is less work than typing using Foo: bar, baz,... .

Even when name is exported, you can just write using Foo; using Foo: name to disambiguate the origin of name.

[DrChainsaw]

Even when name is exported, you can just write using Foo; using Foo: name to disambiguate the origin of name .

Wow, I had no idea it worked like that! I guess I should have tried @rdeits suggestion before complaining

[GunnarFarneback]

@Tamas_Papp

Personally I think 1 and 2 are fine options, depending on the API and whether it is intended for interactive use or package code. For the latter, using everything explicitly is fine and is a good habit.

For package code it’s not only a good habit but a necessity if you take semantic versioning seriously. Assume you have the code

using Dep1
using Dep2

and declare compat

[compat]
Dep1 = "1"
Dep2 = "1"

Let’s assume this works fine without collisions for version 1.0 of both dependencies. Unfortunately Dep2 then adds a new feature which exports a name that you are already using from Dep1. Dep2 correctly bumps the minor version and releases “1.1”, which is within the compat you have declared, but your package breaks due to the conflict.

To avoid this scenario you either have to use explicit usings or defensively declare tilde compats (i.e. only allow patch upgrades), but the latter will likely drive both you and your users crazy.

(Of course you may take the likelihood of conflicts into consideration, e.g. if you’re only using stdlibs or you have control of the dependencies yourself. This scenario also doesn’t apply to a single using, although explicit using would still be a good habit.)

[DrChainsaw]

This was very much related to my original concern. My current mindset is that this is a normal oopsie/bug/breakage and should just be treated as such. Users can handle it by pinning versions of dependencies (assuming they can figure out what went wrong) and thanks to the disambiguation trick (haven’t tried it yet to see if it works though) quick fixes are trivial.

It is always good to have strategies to avoid such things and I suppose the explicit import strategy is one such strategy.

[Tamas_Papp]

@GunnarFarneback

a necessity if you take semantic versioning seriously.

Excellent point, perhaps this should be mentioned in the namespaces section of the manual.

[cscherrer]

@DrChainsaw

Even when name is exported, you can just write using Foo; using Foo: name to disambiguate the origin of name .

Wow, I had no idea it worked like that! I guess I should have tried @rdeits suggestion before complaining

I had no idea you could do this; I’ve often wished we could do using Bar hiding name.

[dilumaluthge]

@cscherrer

I’ve often wished we could do using Bar hiding name .

I think this could be a good feature. Something like:

using SomePackage except: Foo, Bar, f, g

[jzr]

Imo the IDE should just add explicit : foo statements when foo is used.

[DrChainsaw]

I could swear that I have seen VS code doing this lately. Unfortunately it has in most cases been an annoyance when I mistype something, but if this is the reason I could certainly start loving that feature.

[DrChainsaw]

I have also yearned for this. To me it seems like using Foo; using Foo: somecollidedname is a working substitute, but I haven’t started exploring it yet.