Re: Weird interaction with public and non-public imports
On Thursday, 28 January 2021 at 13:13:46 UTC, Paul Backus wrote: ... https://issues.dlang.org/show_bug.cgi?id=21589 These issues are always so subtle and specific yet so annoying, e.g.: https://issues.dlang.org/show_bug.cgi?id=21496 and https://issues.dlang.org/show_bug.cgi?id=21377
Re: Weird interaction with public and non-public imports
On Thursday, 28 January 2021 at 13:07:13 UTC, SealabJaster wrote: Please see: https://run.dlang.io/is/2mwcPH I'd expect that the `isInstanceOf` would be true instead of false here. Commenting out the public import changes the output of `fullyQualifiedName`. I can kind of see why this happens, but it's kind of annoying when things like `isInstanceOf` silently fail due to this. Looks like a bug to me. I recommend filing a bug report on issues.dlang.org.
Weird interaction with public and non-public imports
Please see: https://run.dlang.io/is/2mwcPH I'd expect that the `isInstanceOf` would be true instead of false here. Commenting out the public import changes the output of `fullyQualifiedName`. I can kind of see why this happens, but it's kind of annoying when things like `isInstanceOf` silently fail due to this. For context: I found this after getting a compiler error after stitching a bunch of D files together, which is why there's a mix of a public import and local import in the same file. Part of me feels like it's a bug since if the alias `T` is using one "version" (for lack of a better word) of `Nullable`, then surely that same "version" would be given to `isInstanceOf`? It can get a bit more interesting as well: https://run.dlang.io/is/n5jzJs
Re: public imports
On Wednesday, 5 December 2018 at 23:18:49 UTC, H. S. Teoh wrote: Maybe if you described to us exactly what you want to do, we could find a way to do it that doesn't involve language holes that are not guaranteed to work? Honestly I don't know. I was just messing around. My initial question was, is this a bug or a feature. For which I got an answer.
Re: public imports
On Wed, Dec 05, 2018 at 10:57:37PM +, Sjoerd Nijboer via Digitalmars-d-learn wrote: [...] > I was trying to get some form of persistant import outside of the > function/template scope in the module scope, depending on the > parameters of the function or template. I hoped I could find > something funny or maybe some usefull trick. Unfortunately I couldn't > :/ [...] Maybe if you described to us exactly what you want to do, we could find a way to do it that doesn't involve language holes that are not guaranteed to work? T -- Spaghetti code may be tangly, but lasagna code is just cheesy.
Re: public imports
On Wednesday, 5 December 2018 at 21:21:12 UTC, Adam D. Ruppe wrote: Looks intended. It doesn't really make sense to have a public import inside a function. I was trying to find a weird corner of the language and maybe do something funny with conditional imports. They don't work in functions, however public imports do work in templates, but act as imports that are only visible in that scope. I was trying to get some form of persistant import outside of the function/template scope in the module scope, depending on the parameters of the function or template. I hoped I could find something funny or maybe some usefull trick. Unfortunately I couldn't :/
Re: public imports
On Wednesday, 5 December 2018 at 21:13:29 UTC, Sjoerd Nijboer wrote: A small question. Is it intended behaviour that public imports inside function calls fail with the message "Error: found public instead of statement", or is it an underdocumented feature? void foo() { public import bar; } An import statment inside a function is already limited to that function's scope, so making it public doesn't really make sense. That said, the language specification [1] doesn't say anything about this kind of import being an error, so it's definitely underdocumented. The error message is also not as good as it could be. [1] https://dlang.org/spec/module.html#scoped_imports
Re: public imports
On Wednesday, 5 December 2018 at 21:13:29 UTC, Sjoerd Nijboer wrote: A small question. Is it intended behaviour that public imports inside function calls fail with the message "Error: found public instead of statement", or is it an underdocumented feature? Looks intended. It doesn't really make sense to have a public import inside a function.
public imports
A small question. Is it intended behaviour that public imports inside function calls fail with the message "Error: found public instead of statement", or is it an underdocumented feature? void foo() { public import bar; }
Re: html documentation should show public imports
On Thursday, 18 July 2013 at 00:39:33 UTC, Timothee Cour wrote: std.range contains public import std.array. There are a few full module public imports like that in phobos. What's the rationale? I understand for hierarchical modules (breaking modules into packages) but for this? I'm pretty sure that std.array is publicly imported since without it an array isn't a range. If your module works on ranges it must support arrays (if your module is template heavy). string[] myList; ... std.algorithm.sort(myList); This would fail if std.array wasn't imported by std.algorithm and there is nothing you'd be able to do about it from outside std.algorithm.
Re: html documentation should show public imports
On Wed, Jul 17, 2013 at 09:21:08PM -0700, Jonathan M Davis wrote: > On Wednesday, July 17, 2013 17:39:19 Timothee Cour wrote: > > std.range shouldn't contain public import std.array. > > It's done because otherwise std.range is useless with arrays, and > arrays are probably the most frequently used type of range. We lose > nothing by having that public import. Now, documenting public imports > is a good idea, but I don't understand why you think that having > std.range publicly import std.array is a problem. [...] We should document public imports. But the whole point of publically importing std.array in std.range is so that you can endow arrays with the range API by importing just std.range. I think we should keep it. Just add it to the documentation. T -- Just because you can, doesn't mean you should.
Re: html documentation should show public imports
On Wednesday, July 17, 2013 17:39:19 Timothee Cour wrote: > std.range shouldn't contain public import std.array. It's done because otherwise std.range is useless with arrays, and arrays are probably the most frequently used type of range. We lose nothing by having that public import. Now, documenting public imports is a good idea, but I don't understand why you think that having std.range publicly import std.array is a problem. - Jonathan M Davis
Re: html documentation should show public imports
Timothee Cour: 1) html documentation should show public imports (sometimes such public imports make sense) 2) std.range shouldn't contain public import std.array. Sounds good. Bye, bearophile
html documentation should show public imports
std.range contains public import std.array. There are a few full module public imports like that in phobos. What's the rationale? I understand for hierarchical modules (breaking modules into packages) but for this? it's a bit confusing, as searching for 'array' in std.range docs yields nothing. My suggestion: 1) html documentation should show public imports (sometimes such public imports make sense) 2) std.range shouldn't contain public import std.array.
Re: Public imports with D interface files?
I wasn't including it on the command line; I thought I didn't need to. That fixed it, thanks! == Quote from David Nadlinger (s...@klickverbot.at)'s article > Are you specifying std_ext/typetuple.di or whatever it is called when > compiling the main module? The public import probably triggers creation > of a module constructor as it really creates aliases for the symbols > from the imported module. > David > On 9/4/11 3:17 AM, Sean Eskapp wrote: > > I'm compiling a very simple D interface file: > > > > module std_ext.typetuple; > > > > public import std.typetuple > > > > class TypeArray(T...) > > { > > } > > > > Compiling it as such: > > dmd -debug -unittest -D -Dddocs -w -H -o- std_ext/typetuple.d > > > > And including it as such: > > > > import std_ext.typetuple; > > > > void main() > > { > > TypeArray!(int, double) blah; > > } > > > > I get a linker error "Symbol Undefined _D7std_ext9typetuple12__ModuleInfoZ" > > > > Removing the public import removes this error. How can I fix this?
Re: Public imports with D interface files?
Are you specifying std_ext/typetuple.di or whatever it is called when compiling the main module? The public import probably triggers creation of a module constructor as it really creates aliases for the symbols from the imported module. David On 9/4/11 3:17 AM, Sean Eskapp wrote: I'm compiling a very simple D interface file: module std_ext.typetuple; public import std.typetuple class TypeArray(T...) { } Compiling it as such: dmd -debug -unittest -D -Dddocs -w -H -o- std_ext/typetuple.d And including it as such: import std_ext.typetuple; void main() { TypeArray!(int, double) blah; } I get a linker error "Symbol Undefined _D7std_ext9typetuple12__ModuleInfoZ" Removing the public import removes this error. How can I fix this?
Public imports with D interface files?
I'm compiling a very simple D interface file: module std_ext.typetuple; public import std.typetuple class TypeArray(T...) { } Compiling it as such: dmd -debug -unittest -D -Dddocs -w -H -o- std_ext/typetuple.d And including it as such: import std_ext.typetuple; void main() { TypeArray!(int, double) blah; } I get a linker error "Symbol Undefined _D7std_ext9typetuple12__ModuleInfoZ" Removing the public import removes this error. How can I fix this?
Re: Why does std.string use public imports?
On 2011-07-01 14:58, Andrej Mitrovic wrote: > On 7/1/11, Jonathan M Davis wrote: > > On 2011-06-30 17:12, Jonathan M Davis wrote: > >> On 2011-06-30 16:14, Andrej Mitrovic wrote: > >> > I'm referring to these two in std.string: > >> > public import std.algorithm : startsWith, endsWith, cmp, count; > >> > public import std.array : join, split; > >> > > >> > Because whenever I try to use .count in my code: > >> > > >> > import std.stdio; > >> > import std.string; > >> > import std.utf; > >> > > >> > void main() > >> > { > >> > writeln("foo".count); > >> > } > >> > > >> > std.utf.count conflicts with std.string's publicly imported > >> > std.algorithm.count > >> > > >> > Can we avoid public imports in modules? The rise of conflicts in > >> > Phobos is getting slightly annoying. > >> > >> I believe that they're there because the functions in question used to > >> be in std.string but were generalized and moved to other modules. So, > >> rather than immediately break code, they were publicly imported in > >> std.string. They're scheduled for deprecation and will be removed once > >> the deprecation process has completed. However, they shouldn't be > >> causing conflicts. It's probably due to a bug related to explicit > >> imports being seen as new functions in the module that they're imported > >> into (I forget the bug number). Maybe using static imports with aliases > >> would fix the problem. > > > > Actually, now that I look at it more closely, the problem that you're > > seeing is fully expected and desired. It's complaining that std.string > > has a count function and that std.utf has a count function and that it > > doesn't know which > > to use. That's exactly what's supposed to happen when two modules have > > functions which conflict. std.string has had a count function for a long > > time. > > So, this is the behavior that you would have seen for a long time. > > std.string's count has been generalized and moved to std.algorithm, so > > you're > > going to get the same conflict between std.algorithm.count and > > std.utf.count - > > which is expected. The public import is part of the deprecation and will > > go away eventually. At that point, std.string and std.utf will no longer > > conflict > > for count, because std.string won't have a count function anymore. But > > there's > > no bug here. What you're seeing here is exactly what std.string and > > std.utf have been doing for some time. It's a natural side effect of > > using the same function name in multiple modules. Using the full module > > path for the function > > fixes the problem (though it doesn't work with the member function call > > syntax > > in that case). It's how the module system works and fully expected. > > > > - Jonathan M Davis > > When did I ever say it was a bug? I said it's annoying that there's > conflicts due to public imports. If it's going away, good. I know > algorithm has count, but I never imported that module, std.string > imported it publicly so I got conflicts even though I was trying to > avoid them. Well, for some functions, conflicts are going to be pretty much inevitable. And the number is only likely to go up as Phobos' size increases. Smart function naming reduces it, but sometimes the best name is the same name as one which already exists, and conflicts are going to happen. They won't normally be public imports like that, but they're going to happen. - Jonathan M Davis
Re: Why does std.string use public imports?
On 7/1/11, Jonathan M Davis wrote: > On 2011-06-30 17:12, Jonathan M Davis wrote: >> On 2011-06-30 16:14, Andrej Mitrovic wrote: >> > I'm referring to these two in std.string: >> > public import std.algorithm : startsWith, endsWith, cmp, count; >> > public import std.array : join, split; >> > >> > Because whenever I try to use .count in my code: >> > >> > import std.stdio; >> > import std.string; >> > import std.utf; >> > >> > void main() >> > { >> > writeln("foo".count); >> > } >> > >> > std.utf.count conflicts with std.string's publicly imported >> > std.algorithm.count >> > >> > Can we avoid public imports in modules? The rise of conflicts in >> > Phobos is getting slightly annoying. >> >> I believe that they're there because the functions in question used to be >> in std.string but were generalized and moved to other modules. So, rather >> than immediately break code, they were publicly imported in std.string. >> They're scheduled for deprecation and will be removed once the deprecation >> process has completed. However, they shouldn't be causing conflicts. It's >> probably due to a bug related to explicit imports being seen as new >> functions in the module that they're imported into (I forget the bug >> number). Maybe using static imports with aliases would fix the problem. > > Actually, now that I look at it more closely, the problem that you're seeing > is fully expected and desired. It's complaining that std.string has a count > function and that std.utf has a count function and that it doesn't know > which > to use. That's exactly what's supposed to happen when two modules have > functions which conflict. std.string has had a count function for a long > time. > So, this is the behavior that you would have seen for a long time. > std.string's count has been generalized and moved to std.algorithm, so > you're > going to get the same conflict between std.algorithm.count and std.utf.count > - > which is expected. The public import is part of the deprecation and will go > away eventually. At that point, std.string and std.utf will no longer > conflict > for count, because std.string won't have a count function anymore. But > there's > no bug here. What you're seeing here is exactly what std.string and std.utf > have been doing for some time. It's a natural side effect of using the same > function name in multiple modules. Using the full module path for the > function > fixes the problem (though it doesn't work with the member function call > syntax > in that case). It's how the module system works and fully expected. > > - Jonathan M Davis > When did I ever say it was a bug? I said it's annoying that there's conflicts due to public imports. If it's going away, good. I know algorithm has count, but I never imported that module, std.string imported it publicly so I got conflicts even though I was trying to avoid them.
Re: Why does std.string use public imports?
On 01.07.2011 22:06, Jonathan M Davis wrote: On 2011-06-30 17:12, Jonathan M Davis wrote: On 2011-06-30 16:14, Andrej Mitrovic wrote: I'm referring to these two in std.string: public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; Because whenever I try to use .count in my code: import std.stdio; import std.string; import std.utf; void main() { writeln("foo".count); } std.utf.count conflicts with std.string's publicly imported std.algorithm.count Can we avoid public imports in modules? The rise of conflicts in Phobos is getting slightly annoying. I believe that they're there because the functions in question used to be in std.string but were generalized and moved to other modules. So, rather than immediately break code, they were publicly imported in std.string. They're scheduled for deprecation and will be removed once the deprecation process has completed. However, they shouldn't be causing conflicts. It's probably due to a bug related to explicit imports being seen as new functions in the module that they're imported into (I forget the bug number). Maybe using static imports with aliases would fix the problem. Actually, now that I look at it more closely, the problem that you're seeing is fully expected and desired. It's complaining that std.string has a count function and that std.utf has a count function and that it doesn't know which to use. That's exactly what's supposed to happen when two modules have functions which conflict. std.string has had a count function for a long time. So, this is the behavior that you would have seen for a long time. std.string's count has been generalized and moved to std.algorithm, so you're going to get the same conflict between std.algorithm.count and std.utf.count - which is expected. The public import is part of the deprecation and will go away eventually. At that point, std.string and std.utf will no longer conflict for count, because std.string won't have a count function anymore. But there's no bug here. What you're seeing here is exactly what std.string and std.utf have been doing for some time. It's a natural side effect of using the same function name in multiple modules. Using the full module path for the function fixes the problem (though it doesn't work with the member function call syntax in that case). It's how the module system works and fully expected. - Jonathan M Davis Isn't it expected that std.string contains a count method? import std.stdio; import std.string; void main() { auto s = "à"; writeln(s.length); // 2 - often you want the actual number of characters, not code points writeln(s.count()); // 1 - should a user need to import count from algorithm/utf to get this? }
Re: Why does std.string use public imports?
On 2011-06-30 17:12, Jonathan M Davis wrote: > On 2011-06-30 16:14, Andrej Mitrovic wrote: > > I'm referring to these two in std.string: > > public import std.algorithm : startsWith, endsWith, cmp, count; > > public import std.array : join, split; > > > > Because whenever I try to use .count in my code: > > > > import std.stdio; > > import std.string; > > import std.utf; > > > > void main() > > { > > writeln("foo".count); > > } > > > > std.utf.count conflicts with std.string's publicly imported > > std.algorithm.count > > > > Can we avoid public imports in modules? The rise of conflicts in > > Phobos is getting slightly annoying. > > I believe that they're there because the functions in question used to be > in std.string but were generalized and moved to other modules. So, rather > than immediately break code, they were publicly imported in std.string. > They're scheduled for deprecation and will be removed once the deprecation > process has completed. However, they shouldn't be causing conflicts. It's > probably due to a bug related to explicit imports being seen as new > functions in the module that they're imported into (I forget the bug > number). Maybe using static imports with aliases would fix the problem. Actually, now that I look at it more closely, the problem that you're seeing is fully expected and desired. It's complaining that std.string has a count function and that std.utf has a count function and that it doesn't know which to use. That's exactly what's supposed to happen when two modules have functions which conflict. std.string has had a count function for a long time. So, this is the behavior that you would have seen for a long time. std.string's count has been generalized and moved to std.algorithm, so you're going to get the same conflict between std.algorithm.count and std.utf.count - which is expected. The public import is part of the deprecation and will go away eventually. At that point, std.string and std.utf will no longer conflict for count, because std.string won't have a count function anymore. But there's no bug here. What you're seeing here is exactly what std.string and std.utf have been doing for some time. It's a natural side effect of using the same function name in multiple modules. Using the full module path for the function fixes the problem (though it doesn't work with the member function call syntax in that case). It's how the module system works and fully expected. - Jonathan M Davis
Re: Why does std.string use public imports?
Andrej Mitrovic Wrote: > I'm referring to these two in std.string: > public import std.algorithm : startsWith, endsWith, cmp, count; > public import std.array : join, split; I'm not sure why they are public, but selective/named imports have been publicly imported for some time. Bugzilla 3?? I think.
Re: Why does std.string use public imports?
On 2011-06-30 16:14, Andrej Mitrovic wrote: > I'm referring to these two in std.string: > public import std.algorithm : startsWith, endsWith, cmp, count; > public import std.array : join, split; > > Because whenever I try to use .count in my code: > > import std.stdio; > import std.string; > import std.utf; > > void main() > { > writeln("foo".count); > } > > std.utf.count conflicts with std.string's publicly imported > std.algorithm.count > > Can we avoid public imports in modules? The rise of conflicts in > Phobos is getting slightly annoying. I believe that they're there because the functions in question used to be in std.string but were generalized and moved to other modules. So, rather than immediately break code, they were publicly imported in std.string. They're scheduled for deprecation and will be removed once the deprecation process has completed. However, they shouldn't be causing conflicts. It's probably due to a bug related to explicit imports being seen as new functions in the module that they're imported into (I forget the bug number). Maybe using static imports with aliases would fix the problem. - Jonathan M Davis
Re: Why does std.string use public imports?
That makes sense, I understand. But I hate these conflicts. I've got `alias std.bla.foo foo` scattered in most of my code due to constant conflicts. :/
Re: Why does std.string use public imports?
On 01.07.2011 01:14, Andrej Mitrovic wrote: I'm referring to these two in std.string: public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; Because whenever I try to use .count in my code: import std.stdio; import std.string; import std.utf; void main() { writeln("foo".count); } std.utf.count conflicts with std.string's publicly imported std.algorithm.count Can we avoid public imports in modules? The rise of conflicts in Phobos is getting slightly annoying. I cannot comment on the count issue, but if I was to import only std.string and I was missing basic functionality like the ones imported here, it would have annoyed me :) So it's good if it makes sense I think.
Why does std.string use public imports?
I'm referring to these two in std.string: public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; Because whenever I try to use .count in my code: import std.stdio; import std.string; import std.utf; void main() { writeln("foo".count); } std.utf.count conflicts with std.string's publicly imported std.algorithm.count Can we avoid public imports in modules? The rise of conflicts in Phobos is getting slightly annoying.
Re: public imports and template functions
On Wednesday 24 November 2010 00:18:44 Don wrote: > Jonathan M Davis wrote: > > Am I correct in my understanding that if you wish a template function > > which is imported from another module to compile correctly without > > requiring other imports in the module that your using the function in > > that the module with the template function needs to publically import > > all of the functions and types that it needs? > > That's only true of mixins. (And for that reason, you should generally > use fully qualified names in mixins). That makes sense (and IMHO is much better behavior that what I was thinking the case was). I usually have so many imports which are common between files that it isn't an issue even with mixins, but it's a good idea to try and get rid of imports that you're not using, and in order to do that properly, you have to understand the import rules. I was afraid that some of my template stuff was working only because so many of the imports were common between files, but fortunately, that's not the case. Thanks for the clarification. - Jonathan M Davis
Re: public imports and template functions
Jonathan M Davis wrote: Am I correct in my understanding that if you wish a template function which is imported from another module to compile correctly without requiring other imports in the module that your using the function in that the module with the template function needs to publically import all of the functions and types that it needs? That's only true of mixins. (And for that reason, you should generally use fully qualified names in mixins).
public imports and template functions
Am I correct in my understanding that if you wish a template function which is imported from another module to compile correctly without requiring other imports in the module that your using the function in that the module with the template function needs to publically import all of the functions and types that it needs? So, if you had -- module a; import std.algorithm; void func(R)(R range) { sort(range); } -- module b; import module a; void foobar(int[] vals) { sort(vals); } -- then you'd have to import std.algorithm (or std.algorithm.sort) in module b, and if you didn't want to require that, you'd do public import std.algorithm : sort; in module a. Is that correct? Or is my understanding off? - Jonathan M Davis