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 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 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.
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: 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
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: 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?
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: 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?
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 7/1/11, Jonathan M Davis jmdavisp...@gmx.com 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 2011-07-01 14:58, Andrej Mitrovic wrote:
On 7/1/11, Jonathan M Davis jmdavisp...@gmx.com 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
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: 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.
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 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?
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.
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
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
