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

Jacob Bandes-Storch jtbandes at gmail.com
Tue Jul 19 16:11:28 CDT 2016 

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
>>
>> > 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
>> <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 <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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Bianca
> http://biancatamayo.me
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160719/62c1aebc/attachment.html>

More information about the swift-evolution mailing list