Fix remaining import deprecation messages #4016
Conversation
|
Thanks a lot. |
| ab = (-lhs) ^^ this.re * exp(-PI * this.im); | ||
| ar = PI * this.re + log(-lhs) * this.im; | ||
| ab = (-lhs) ^^ this.re * std.math.exp(-std.math.PI * this.im); | ||
| ar = std.math.PI * this.re + std.math.log(-lhs) * this.im; |
There was a problem hiding this comment.
IMO, in math-related code such as std/complex.d it's only natural to use log and PI directly, instead of the ugly FQN's. What about making this one a selective import instead?
There was a problem hiding this comment.
Yeah import std.math : cos, exp, log, sin would be a bit nicer, in fact since hijacking of local symbols was fixed import std.math would be an option as well.
There was a problem hiding this comment.
This was the trickiest file. Because std.complex has some of the exact same symbols as std.math
I asked myself the question, "what are the chances that std.complex will gain a definition for PI, log, etc.?", so I just went with the static import. There are other places I have no choice (example, sqrt).
There was a problem hiding this comment.
I'll note that with new rules, the current module takes precedent over any imports, even scoped ones. So using selective imports may break later if these symbols get added.
There was a problem hiding this comment.
Hmm, you're right, std.complex quite possibly may implement its own version of log, exp, etc.. But wouldn't they be adequately disambiguated by the argument type? Or would that still be a conflict under current rules?
There was a problem hiding this comment.
The current file takes precedence I think, but not quite sure. So the compiler (I think) will stop looking for the symbol if it finds it in the current module, regardless of whether the overload would work elsewhere.
There was a problem hiding this comment.
I'm wrong, I tested it out. Apparently, if you import selectively, that overrides any local module symbols. Is that the way it's supposed to work?
There was a problem hiding this comment.
Update: yep, dlang.org specifies this behavior. A selective import binds it to the current namespace.
I'll work on re-fixing these.
|
Other than that, LGTM. Let's get this in sooner rather than later. |
|
Redid some of the static imports as selective, and fixed the assert spacing. |
|
LGTM |
|
Auto-merge toggled on |
Fix remaining import deprecation messages
See #4015
This is the rest of them.
There are some places where it's not 100% clear whether the right call is a static import or a selective import.
This should be merged fairly quickly, because it touches a lot of files, the risk of this becoming conflicting is pretty high.