Skip to content

Conversation

MartinNowak
Copy link
Member

No description provided.

calling $(D to!string)) when retention is needed. If the caller needs
to retain a copy of every line, use the $(LREF byLineCopy) function
calling $(D to!string)) when retention is needed. If the caller needs
to retain a copy of every line, use the $(LREF byLineCopy) function
instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm? What got changed here? Whitespace? I can't see any difference in this diff.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't see any difference in this diff.

Line ending?

@quickfur
Copy link
Member

quickfur commented Aug 1, 2014

Overall, LGTM. I think this is an important direction to take; it should get us closer to the point where monsters like std.algorithm will lend itself to be split up into submodules more easily. Currently there are too many dependencies on global imports, and the last time I tried to extricate different parts of it into separate submodules, I failed, horribly.

@mihails-strasuns
Copy link

LGTM

@mihails-strasuns
Copy link

Auto-merge toggled on

mihails-strasuns pushed a commit that referenced this pull request Aug 2, 2014
@mihails-strasuns mihails-strasuns merged commit f7011bd into dlang:master Aug 2, 2014
@Orvid
Copy link
Contributor

Orvid commented Aug 2, 2014

I vote to call this process scoping imports rather than localizing them, due to the word localize typically being used in the context of internationalization and translation of strings. (I was confused at first how you could localize an import when I saw the merge notification on the IRC)

@@ -742,6 +742,7 @@ string toHexString(Order order = Order.increasing, LetterCase letterCase = Lette
result[i++] = hexDigits[u & 15];
}
}
import std.exception : assumeUnique;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one will obviously be different, as it's already merged, but aren't imports usually declared at the start of the inner-most scope where they're used, rather than right before they're used?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no strict policies about it I am aware of. I personally would favor such style (beginning of scope) too but it doesn't seem critical.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember @9rnsr once asking for imports to go at the top of a local scope, as failure to do so could introduce subtle name resolution bugs. I can't remember how though.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The explanation is here: #1813. Though I don't completely buy it though, I guess one could argue it's good style anyways?

@monarchdodra
Copy link
Collaborator

I vote to call this process scoping imports rather than localizing them, due to the word localize typically being used in the context of internationalization and translation of strings. (I was confused at first how you could localize an import when I saw the merge notification on the IRC)

Ditto.

@MartinNowak MartinNowak deleted the localizeImports branch August 2, 2014 07:45
@MartinNowak
Copy link
Member Author

We need tooling for this, it's too error prone to do by hand.
Writing a tool is also difficult, because it also has to check uninstantiated template declarations.
Not to mention, that it needs a D parser and AST.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants