Closed DartBot closed 9 years ago
This comment was originally written by @ahmetaa
IMHO, you should provide stronger reasoning for this request. AFAIK, there are other reasons than ambiguity for this change (something with VM internals?). The only problem comes to my mind, porting code takes more time with this. But it is almost an automatic process so It is not a big deal. I got used to the new syntax in very short time.
This comment was originally written by d.connec...@gmail.com
In response to Comment 1 ...
I use string concatenation on a regular basis. It is important to keep the syntax as compact and non-verbose as possible. The "+" operator achieves this. In the past, I have used Java class methods (e.g., StringBuffer.append) to concatenate strings, and I certainly agree that the learning/habit curve for this approach is quite shallow. Still, the resulting code is often unnecessarily bloated.
The Dart language appears to be evolving with some really impressive and useful features -- features that I suspect may be adopted in some form by other languages. That said, I believe that it is well within the capability of the innovative Dart language engineers to figure out a way to retain the string concatenation operator, even if the solution requires a little attention to core components of their VM. I'm sure that there will be many potential Dart developers who would appreciate restoration of the concatenation operator.
cc @floitschG. cc @lrhn. Removed Type-Defect label. Added Type-Enhancement, Area-Library, Triaged labels.
While I'm sympathetic to compiler internal problems (and I'm familiar with the problems in, e.g., dart2js), it should not be the deciding factor in how we design the libraries. Every user class can override operator+, so there shouldn't be a huge technical problem on doing it in String. I.e., the VM can adapt, and the libraries should be designed for the user, not the implementation, as long as it's not completely impossible to make it work. And dart2js may suffer a small overhead.
This comment was originally written by @butlermatt
To be honest, apart from easy of porting JS code, I'm not sure how much would be gained by re-instating the + for string concatenation, with the multiple other options we already have available -
adjacent string literals: 'one long ' 'concatenated ' 'string';
string interpolation: var str = 'my string'; var me = 'I love $str.';
string buffers, already mentioned in previous comment. I believe are also more efficient than creating multiple strings by using multiple concatenation operators, but that's something I'm sure could be overcome with some source analysis (particularly when compiling either dart2dart or dart2js).
Whereas the ambiguous situations can arrive relatively easily. var elm = 23; var str = "23";
elm + str; // Error str + elm; // Ok.
This issue was originally filed by d.connec...@gmail.com
What steps will reproduce the problem?
What is the expected output? What do you see instead? The expected result is a new string formed from the concatenation of two strings on either side of the plus operator.
What version of the product are you using? On what operating system? N/A - this defect is per the latest changes to the Dart language.
Please provide any additional information below.
Dart language architects should re-consider removal of the plus operator for String concatenation. Although ambiguities can arise with the plus operator, the majority of use cases are likely to be unambiguous. Discarding the concatenation operator due to problematic but infrequent use cases is like throwing out the baby with the bathwater.
Perhaps the Dart compiler could generate a warning (but not an error) when the plus sign is used in an ambiguous situation (e.g., where the order of input variables/literals would impact the inferred type). The warning would indicate how Dart will interpret the ambiguous code. Of course, with this type of warning, it would be helpful to give developers the ability to do something like @SuppressWarnings([operator ambiguity]) to override the warning, but even without this ability to suppress the warning, this warning-oriented approach would be better than simply discarding the serviceable concatenation operator.