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

Ted F.A. van Gaalen tedvgiosdev at gmail.com
Wed Jul 20 20:49:15 CDT 2016


Don’t Panic !

At the risk of seeing things in a somewhat trivial perspective,
combined with an almost complete absence of abstraction:

Note that to relatively simple persons like me: 

String instances are just rows of characters (when not empty, of course) 

There are only two kinds of Strings:

1. empty Strings, which do not contain amy characters at all

  and 

2.  Strings containing 1 or more characters.

Ergo ad Infinitum :

Empty Strings do not occur in Strings that contain characters. 


I’d say, please try to find possible empty strings
that might perhaps be embedded e.g. in the string below: 
 
“Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42” 


With all due respect: 
This might void the discussion below :o)

I have nothing against Mathematics as long
as it is applicable.


Kind Regards
Ted



> To the question of whether any given string has the empty string as prefix:
> yes it does. This is a correct answer, and returning true is a correct
> behaviour.
> 
> To the question of how many times the empty string occurs in a string: yes,
> this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" + "" + "" +
> "" == "a" + "" + "" + "" + "" == ... etc.. Concatenating an empty string,
> like adding zero or multiplying by zero for a numerical value, can be done
> infinitely many times without making a difference.
> 
> However, there's correctness and convenience. For example, every integer
> can be expressed as a multiple of prime factors. 1 is technically a prime
> number - it's divisible by 1 and itself - but for convenience we say it
> isn't a prime number, because if it isn't, every integer can be expressed
> uniquely as a multiple of prime factors, whereas if it is, there are an
> infinite number of such expressions for each integer.
> 
> There may be many algorithms which rely on an empty prefix returning false.
> If hasPrefix and hasSuffix are corrected, those algorithms should be
> altered to recognise that correction. For example, if breaking up a string
> using the empty string as a separator, it seems sensible that the sequence
> of substrings would never contain consecutive empty strings.
> 
> On Wed, Jul 20, 2016 at 11:58 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I'd run this by someone who actually knows math, but afaik there are
>> finitely many empty strings in any given string.
>> 
>> How many e's are in any given string? (Ignoring Unicode issues for now,)
>> for each index in the string's indices, form a substring one character in
>> length starting at that index and compare the value of that substring to e.
>> 
>> How many empty strings are in any given string? For each index in the
>> string's indices, form a substring zero characters in length starting at
>> that index and compare the value of that substring to an empty string.
>> 
>> 
>> 
>> On Wed, Jul 20, 2016 at 17:35 Guillaume Lessard <
>> glessard at tffenterprises.com <mailto:glessard at tffenterprises.com>> wrote:
>> 
>>> 
>>>> On 20 juil. 2016, at 14:21, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>>>> 
>>>> Doesn't your second argument undermine your first? If it's a trivial
>>> solution and one rarely ever considers empty strings when invoking
>>> `hasPrefix`, then returning the technically correct result must be a
>>> trivial departure in behavior.
>>> 
>>> I specifically used an example where the trivial solution (y=0 instead of
>>> y=exp(x)) is a pitfall.
>>> 
>>> How many empty strings are contained in any given string?
>>> If the answer is infinitely many, it sounds like a pitfall to me.
>>> 
>>> Cheers,
>>> Guillaume Lessard
>>> 
>>> 
>> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/f4fb7b6e/attachment.html>


More information about the swift-evolution mailing list