digitalmars.D - std.string import cleanup: how to fix regression?
- H. S. Teoh via Digitalmars-d (22/23) Nov 12 2014 Recently, Ilya has been helping to clean up import dependencies between
- Ilya Yaroshenko (6/12) Nov 12 2014 One solution is new `extern import std.array : split;` syntax.
- Dicebot (3/3) Nov 12 2014 Will this work?
- Daniel Kozak (4/7) Nov 13 2014 Yes, but not for all cases. If I have code where I import
- Daniel Kozak (11/19) Nov 13 2014 But this can be solved by something like this:
- Daniel Kozak (9/40) Nov 13 2014 What about:
- Ilya Yaroshenko (1/8) Nov 13 2014
- H. S. Teoh via Digitalmars-d (8/19) Nov 13 2014 Maybe we should file an enhancement request to make alias deprecatable.
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (39/40) Nov 13 2014 It can. But evidently, static import cannot be selective:
Recently, Ilya has been helping to clean up import dependencies between Phobos module. In the course of cleaning up std.string, a few public imports were removed because they were not referenced by the module itself. However, this caused a regression: https://issues.dlang.org/show_bug.cgi?id=13717 The code that got removed was: ------ //Remove when repeat is finally removed. They're only here as part of the //deprecation of these functions in std.string. public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; ------From the comment, it seems clear that the intent is to move thesefunctions out of std.string into std.algorithm and std.array. However, there is currently no way to deprecate public imports, so we can't get rid of this dependency without breaking user code (one of my projects already doesn't compile because of this). What should we do? Anybody has a good idea for getting rid of the gratuitous dependency on std.algorithm / std.array without breaking user code with no warning? T -- EMACS = Extremely Massive And Cumbersome System
Nov 12 2014
One solution is new `extern import std.array : split;` syntax. Like `public` but do *not* visible for module itself. If user will use selective imports with std.string, than there compiler can deduce dependencies without full imports. Furthermore we can deprecate it lately with `deprecated extern import std.array : split;`What should we do? Anybody has a good idea for getting rid of the gratuitous dependency on std.algorithm / std.array without breaking user code with no warning? T
Nov 12 2014
Will this work? static import std.string; deprecated public alias split = std.string.split;
Nov 12 2014
On Wednesday, 12 November 2014 at 17:52:27 UTC, Dicebot wrote:Will this work? static import std.string; deprecated public alias split = std.string.split;Yes, but not for all cases. If I have code where I import std.string and use std.algoritm.startsWith(...), then it would not work
Nov 13 2014
On Thursday, 13 November 2014 at 08:18:22 UTC, Daniel Kozak wrote:On Wednesday, 12 November 2014 at 17:52:27 UTC, Dicebot wrote:But this can be solved by something like this: deprecated { static struct std { static struct algorithm { static import std.algorithm; alias startsWith = std.algorithm.startsWith; } } } However than you can`t use global importsWill this work? static import std.string; deprecated public alias split = std.string.split;Yes, but not for all cases. If I have code where I import std.string and use std.algoritm.startsWith(...), then it would not work
Nov 13 2014
On Wednesday, 12 November 2014 at 17:27:18 UTC, H. S. Teoh via Digitalmars-d wrote:Recently, Ilya has been helping to clean up import dependencies between Phobos module. In the course of cleaning up std.string, a few public imports were removed because they were not referenced by the module itself. However, this caused a regression: https://issues.dlang.org/show_bug.cgi?id=13717 The code that got removed was: ------ //Remove when repeat is finally removed. They're only here as part of the //deprecation of these functions in std.string. public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; ------What about: static import std.algorithm : startsWith, endsWith, cmp, count; static import std.array : join, split; deprecated { alias startsWith = std.algorithm.startsWith; ... }From the comment, it seems clear that the intent is to move thesefunctions out of std.string into std.algorithm and std.array. However, there is currently no way to deprecate public imports, so we can't get rid of this dependency without breaking user code (one of my projects already doesn't compile because of this). What should we do? Anybody has a good idea for getting rid of the gratuitous dependency on std.algorithm / std.array without breaking user code with no warning? T
Nov 13 2014
alias can not be deprecated :-(What about: static import std.algorithm : startsWith, endsWith, cmp, count; static import std.array : join, split; deprecated { alias startsWith = std.algorithm.startsWith; ... }
Nov 13 2014
On Thu, Nov 13, 2014 at 07:27:57PM +0000, Ilya Yaroshenko via Digitalmars-d wrote:alias can not be deprecated :-(Maybe we should file an enhancement request to make alias deprecatable. I know recently someone asked for the 'module' declaration to be deprecatable, and it was implemented. Maybe it's time to extend that to aliases too. :-) T -- There's light at the end of the tunnel. It's the oncoming train.What about: static import std.algorithm : startsWith, endsWith, cmp, count; static import std.array : join, split; deprecated { alias startsWith = std.algorithm.startsWith; ... }
Nov 13 2014
On Thursday, 13 November 2014 at 19:27:59 UTC, Ilya Yaroshenko wrote:alias can not be deprecated :-(It can. But evidently, static import cannot be selective: aa.d: static import std.algorithm;// : startsWith, endsWith, cmp, count; static import std.array;// : join, split; deprecated { alias startsWith = std.algorithm.startsWith; } bb.d: import aa; bool test() { return "".startsWith(""); } bb.d(2): Deprecation: alias aa.startsWith is deprecated Remove ";//" to enable the selective imports, and we get errors: aa.d(1): Error: static import std cannot have an import bind list aa.d(1): Error: static import __anonymous cannot have an import bind list aa.d(1): Error: static import __anonymous cannot have an import bind list aa.d(1): Error: static import __anonymous cannot have an import bind list aa.d(2): Error: static import std cannot have an import bind list aa.d(2): Error: static import __anonymous cannot have an import bind list This seems like an arbitrary restriction. [1] states that it is disallowed (under the heading "Selective Imports"), but gives no justification. It's probably because of the implementation. Anyway, the imports can be pulled into the `deprecated` block to make the intention clear: deprecated { static import std.algorithm; static import std.array; alias startsWith = std.algorithm.startsWith; } [1] http://dlang.org/module
Nov 13 2014