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

Ted F.A. van Gaalen tedvgiosdev at gmail.com
Thu Jul 21 10:46:19 CDT 2016


> 
> There are many empty strings in that string. In fact, there are infinite empty strings between each character, before the string, and after the string. Observe:
> 
> "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> etc, and I didn't even get past the first character!
> 

Wel, maybe I am not intelligent enough to comprehend that,
or maybe it’s just a matter of definition/convention..
 
Again, to me a string is ***just a row of characters***. 

therefore, concatenating empty strings (that do not contain any characters)  with other strings have no effect: . 
for example: 

       let res = "" + "" + "" + "" + “The Art Of Learning To Fly”

after that: 
  
     res == “The Art Of Learning To Fly”

and:

     res.count == “The Art Of Learning To Fly”.count

Regardless what in many  other programming languages  is done;
I prefer the Objective jC NSString hasPrefix(“") way of handling this,
which always returns False,e because a row of characters
is contiguous, without empty “” in between, leading or trailing.  

However, we don’t seem to share the same opinion, about this sorry. 
nothing more to say about that, I guess.

TedvG



>> On Jul 20, 2016, at 6:49 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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
>>>>> 
>>>>> 
>>>> _______________________________________________
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160721/5fb56edf/attachment-0001.html>


More information about the swift-evolution mailing list