> On Jul 19, 2016, at 6:17 PM, Ted F.A. van Gaalen via swift-evolution > <[email protected]> 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 <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
