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

[Charlie Monroe]

> On Jul 19, 2016, at 6:17 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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? 

Empty set is a subset of all sets. 

Just like:

let arr1: [String] = ["Hello", "Swift", "Evolution"]
let arr2: [String] = []
arr1.starts(with: arr2, isEquivalent: ==) // true

>    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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution