[swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen]

ok, Dave



to me - strings being collections -, all I see is:
trying to find an empty string within another string: There are (at least) two ways of treating this:

1.  return “false”  seems to me logically correct, because
     there is never an empty string in another string, and an empty string cannot contain another empty string, right? 
    This has worked very conveniently for NSString in ObjC for more than 20 years, why change it? 
    Do you know of cases that were problematic with this convention? 
   

2  throw a runtime error when trying to do this:
    str.hasPrefix(“”)     //  also for hasSuffix,  str.contains etc.

some in-line questions below.

Kind Regards

Ted


On 19.07.2016, at 16:31, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Tue Jul 19 2016, "Ted F.A. van Gaalen" <tedvgiosdev-AT-gmail.com> wrote:
> 
>> Hi Dave
>> 
>> “true” ? am I going nuts ? :o) 
>> 
>> var str = "Hello, playground"
>> 
>> print( str.hasPrefix("”)) // case 1 : false
>> 
>> print( str.hasSuffix("”)) // case 2 : false
>> 
>> print("" == “a” )          // case 3 : false
>> 
>> Currently, all cases above evaluate to “false”
>> i think that is correct, 
> 
> I don't know what to tell you.  It may seem intuitively correct to you,
> but others in the thread have laid out the reasons why it is not
> mathematically correct behavior.  
Where? I couldn’t find any. 
> One other way of rephrasing it: to get
> `false` for str.hasPrefix(""), you actually need special-case code in
> hasPrefix to check for the empty string,
again, maybe it should throw a run-time error instead.


> and the caller may well also
> need special-case code to handle the fact that the result is not
> mathematically consistent with other cases on the continuum.
In this context as “continuum” : 
   are you referring to  “sets” or “collections” here?
what other cases? 

>  Doing
> things that way doesn't work in practice for real programs.
please explain thank you, because I see no problems at
all with the current NSString-like evaluation…
I’d put an s.isEmpty() in front of it.
> 
>> because:
>> 
>> How can an empty string be a prefix or suffix value?
>> as there is no empty string present in a non-empty string. 
>> 
>> Note that if case 1 and case 2 would evaluate to “true”, 
>> it would conflict with case 3. 
>> 
>> Can’t imagine that case 3 should in future also result in “true” 
>> 
>> ??
>> 
>> -----
>> 
>> Also I hope that changes to String functionality
>> for Swift 4 are not backward breaking changes
>> even the more for string handling, because Strings 
>> are heavily used in most apps. 
>> 
>> I am firmly convinced that all future releases of Swift 
>> should compile Swift 3 and higher source files without
>> any changes 100 % flawlessly! This prevents early diminishing 
>> of Swift’s popularity, especially with those building large
>> codebases using Swift. 
>> 
>> I’ve started a thread about this a week ago,
>> however no one found this important enough to
>> share their opinions with me yet, or were too busy with
>> other subjects to do so.
>> 
>> Increasingly I have dreams, me
>> programming complete apps in Smalltalk
>> and then automagically generate 
>> an macOS, tvOS or iOS runtime app of it.
>> 
>> (I have also dreams of this world becoming
>> a nice and peaceful placebut that is 
>> beyond the context of this forum)    
>> 
>> Kind Regards
>> TedvG 
>> 
>> www.speyer.de
>> 
>>> on Mon Jul 18 2016, Kevin Nattinger <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> I agree, true is definitely the expected behavior. In particular, it
>>>> seems absurd to me that `a.hasPrefix(b)` and `a.hasSuffix(b)` could be
>>>> false when `a == b` is true.
>>> 
>>> I expect to be reworking Strings for Swift 4, and this is one of the
>>> many things we plan to address.
>>> 
>>> -- 
>>> Dave
>>> 
>>> 
>> 
> 
> -- 
> Dave