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.
“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?
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.
On 19.07.2016, at 16:31, Dave Abrahams <email@example.com> wrote:
on Tue Jul 19 2016, "Ted F.A. van Gaalen" <tedvgiosdev-AT-gmail.com> wrote:
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)
on Mon Jul 18 2016, Kevin Nattinger <firstname.lastname@example.org <mailto:email@example.com>> 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.