Raw String Literal Library Support

[Peter Levart]

I think that:

String delim = ...;
String r = 
s.splits(Pattern.quote(delim)).collect(Collectors.joining(delim));

... should always produce a result such that r.equals(s);


Otherwise, is it wise to add methods that take a regex as a String? It 
is rarely needed for a regex parameter to be dynamic. Usually a constant 
is specified. Are there any plans for Java to support Pattern constants? 
With constant dynamic support they would be trivial to implement in 
bytecode. If there are any such plans, then the methods should perhaps 
take a Pattern instead.

syntax suggestion:

'~' is an unary operator for bit-wise negation of integer values. It 
could be overloaded for String(s) such that the following two were 
equivalent:

~ string
Pattern.compile(string)

Now if 'string' above is a constant, '~ string' could be a constant too. 
Combined with raw string literals, Pattern constants could be very compact.


What do you think?

Regards, Peter

On 03/14/2018 02:35 AM, Xueming Shen wrote:
> On 3/13/18, 5:12 PM, Jonathan Bluett-Duncan wrote:
>> Paul,
>>
>> AFAICT, one sort of behaviour which String.split() allows which
>> Pattern.splitAsStream() and the proposed String.splits() don't is 
>> allowing
>> a negative limit, e.g. String.split(string, -1).
>>
>> Over at http://errorprone.info/bugpattern/StringSplitter, they argue 
>> that a
>> limit of -1 has less surprising behaviour than the default of 0, because
>> e.g. "".split(":") produces [] (empty array), whereas ":".split(":")
>> produces [""] (array with an empty string), which IMO is not consistent.
>>
>> This compares with ":".split(":", -1) and "".split(":", -1) which 
>> produce
>> ["", ""] (array with two empty strings, each representing ends of 
>> `:`) and
>> [] (empty array) respectively - more consistent IMO.
>>
>> Should String.splits(`\n|\r\n?`) follow the behaviour of 
>> String.split(...,
>> 0) or String.split(..., -1)?  I'd personally argue for the latter.
>
> While these look really confusing, but ":".split(":", n) and 
> "".split(":", n) are really two
> different scenario. One is for a matched delimiter and the other is a 
> split with no
> matched delimiter, in which the spec specifies clearly that it returns 
> the original string,
> in this case the empty string "". Arguably these two don't have to be 
> "consistent".
>
> Personally I think the returned list/array from string.split(regex, 
> -1) might be kinda of
> "surprising" for end user, in which it has a "trailing" empty string, 
> as it appears to be
> useless in most use scenario and you probably have to do some special 
> deal with it.
>
> -Sherman
>
>
>
>>
>> Cheers,
>> Jonathan
>>
>> On 13 March 2018 at 23:22, Paul Sandoz<paul.sandoz at oracle.com>  wrote:
>>
>>>
>>>> On Mar 13, 2018, at 3:49 PM, John Rose<john.r.rose at oracle.com>  wrote:
>>>>
>>>> On Mar 13, 2018, at 6:47 AM, Jim Laskey<james.laskey at oracle.com>  
>>>> wrote:
>>>>> …
>>>>> A. Line support.
>>>>>
>>>>> public Stream<String>  lines()
>>>>>
>>>> Suggest factoring this as:
>>>>
>>>> public Stream<String>  splits(String regex) { }
>>> +1
>>>
>>> This is a natural companion to the existing array returning method 
>>> (as it
>>> was the case on Pattern when we added splitAsStream), where one can 
>>> use a
>>> limit() operation to achieve the same effect as the limit parameter 
>>> on the
>>> array returning method.
>>>
>>>
>>>> public Stream<String>  lines() { return splits(`\n|\r\n?`); }
>>>>
>>> See also Files/BufferedReader.lines. (Without going into details
>>> Files.lines has some interesting optimizations.)
>>>
>>> Paul.
>