Bug 13808 – Scoped import in struct body hijacks UFCS

///////////////// test.d ///////////////// import std.datetime; import std.string; string format(SysTime s) { return "foo"; } void main() { SysTime s; s.format(); } ////////////////////////////////////////// test.d(9): Error: template std.format.format cannot deduce function from argument types !()(), candidates are: C:\Soft\dmd2d\windows\bin\..\..\src\phobos\std\format.d(6373): std.format.format(Char, Args...)(in Char[] fmt, Args args) Introduced in https://github.com/D-Programming-Language/phobos/pull/2681

I think perhaps the correct change is to import format only inside those functions that need it.

Argh... yet another scoped import pathological behaviour. Apparently putting an import in the body of a struct S pulls symbols into the struct's namespace, so that S.symbol now refers to the imported symbol. This is really nasty, and greatly limits the usefulness of scoped imports, for example: ----- // mod.d module mod; struct S { // This is necessary for myFunc, and we can't move it inside myFunc, // because we need it in the sig constraint import std.range.primitives : isInputRange; auto myFunc(R)(R input) if (isInputRange!R) { ... } } // main.d import mod; void main() { S s; static if (s.isInputRange!(int[])) { // this actually works :-( ... } static if (isInputRange!(int[])) { // whereas this doesn't compile } } ----- Note that making the import in S static doesn't help, because static imports cannot bind specific symbols, so you have to alias specific import symbols... but that again leaks them to the outside via UFCS. This is no longer just about std.datetime, this is a glaring hole in the import system.

Workaround for std.datetime: https://github.com/D-Programming-Language/phobos/pull/2780 This is not a complete fix, as there are a bunch of other scoped imports as well, and it would take quite a bit more effort to sort all of them out. :-( In any case, it's probably better if we address this in the compiler instead of putting workarounds into every library that uses scoped imports at the struct/class level.

(In reply to hsteoh from comment #2) > Argh... yet another scoped import pathological behaviour. Apparently putting > an import in the body of a struct S pulls symbols into the struct's > namespace, so that S.symbol now refers to the imported symbol. Any imported symbols in struct body scope should not be visible via the struct instance object. > This is really nasty, and greatly limits the usefulness of scoped imports, > for example: > > ----- > // mod.d > module mod; > struct S { > // This is necessary for myFunc, and we can't move it inside myFunc, > // because we need it in the sig constraint > import std.range.primitives : isInputRange; > > auto myFunc(R)(R input) > if (isInputRange!R) > { ... } > } > > // main.d > import mod; > void main() { > S s; > static if (s.isInputRange!(int[])) { // this actually works :-( > ... > } > static if (isInputRange!(int[])) { // whereas this doesn't compile > } > } > ----- My import mechanism improvement will disallow the weird name lookup `s.isInputRange!(int[])`. https://github.com/D-Programming-Language/dmd/pull/3407

Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/6473aefc71c6b5c5183fdf150d6528c865a741ad Merge pull request #2780 from quickfur/issue13808 Issue 13808: Don't import std.format in any public scope.

Since the reported regression is fixed, I am lowering the severity to conform to the new issue title.

Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/6473aefc71c6b5c5183fdf150d6528c865a741ad Merge pull request #2780 from quickfur/issue13808

Just tested the following: --- foo.d module foo; import bar; string format(MyStruct s) { return "foo"; } void main() { MyStruct s; s.format(); } --- bar.d module bar; struct MyStruct { import std.format : format; uint value; } --- It works nowadays. I'm pretty sure this was fixed when DIP22 was implemented, aka the two-phases lookup.