Not that it's needed, but another +1 from me. a.hasPrefix(p) should be true iff there exists some string x for which p+x == a. If p == "", then x := a satisfies this, so hasPrefix should return true.
Jacob On Tue, Jul 19, 2016 at 1:29 PM, Jaden Geller via swift-evolution < [email protected]> wrote: > Both `hasPrefix` and `hasSuffix` are analogous to the more general > `hasSubset` function, which would return `true` for the empty set. > > On Jul 19, 2016, at 12:32 PM, Bianca via swift-evolution < > [email protected]> wrote: > > > Empty set is a subset of all sets. > > True but all sets certainly do not _contain_ the empty set, which is what > might be confusing, as the word "contains" in the context of sets implies > that it's a member of the set of characters that make up a String. > > On Tue, Jul 19, 2016 at 12:23 PM Charlie Monroe via swift-evolution < > [email protected]> wrote: > >> >> > 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 >> <http://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 >> > -- > Bianca > http://biancatamayo.me > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
