# [VOTE] Voting opens for str_starts_with and ends_with functions

- Thread: https://externals.io/message/106169
- Original archive: https://news-web.php.net/php.internals/106169
- Started by Andrew Gromov on 2019-07-08T13:05:20+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #106169 — Andrew Gromov — 2019-07-08T13:05:20+00:00

URL: https://externals.io/message/106169#106169

> Please don't switch behaviours via flags: separate names and
> implementations are much clearer and much simpler to follow.
> 
> Yes, you will have multiple variations, but that's fine.


It is depends of preferences.

In my opinion, create new function for every possible situation is more worse
then use flags.



Python


str.startswith(prefix[, start[, end]]) -> bool



C#


public bool StartsWith (string value, bool ignoreCase,
System.Globalization.CultureInfo culture);


public bool StartsWith (string value, StringComparison comparisonType);



JS


str.startsWith(searchString[, position])



Kotlin


fun String.startsWith(prefix: String, startIndex: Int = 0, ignoreCase: Boolean =
false): Boolean



R


startsWith(str, pattern, trim=FALSE, ignore.case=FALSE)



Scala


startsWith[B](that: GenSeq[B], offset: Int): Boolean


Golang, java, C++, Ruby, Swift have simples syntax, like
string.startsWith(prefix)



C#, Kotlin, R uses flag for ignore case.


Anyway, I can't find language from various TOP-lists where present separate
function for case insensitive operations.


Another note - I see that many languages provide “start_index” parameter for
start_with functions.


So… As I say - this is good rfc in perspective, but more discussion is needed.

---

## #106170 — Christoph M. Becker — 2019-07-08T13:20:48+00:00

URL: https://externals.io/message/106169#106170

> > […]
>
>
> It is depends of preferences.
>
> In my opinion, create new function for every possible situation is more
> worse
> then use flags.
>
>
>
> Python
>
>
> str.startswith(prefix[, start[, end]]) -> bool
>
>
>
> C#
>
>
> public bool StartsWith (string value, bool ignoreCase,
> System.Globalization.CultureInfo culture);
>
>
> public bool StartsWith (string value, StringComparison comparisonType);
>
>
>
> JS
>
>
> str.startsWith(searchString[, position])
>
>
>
> Kotlin
>
>
> fun String.startsWith(prefix: String, startIndex: Int = 0, ignoreCase:
> Boolean =
> false): Boolean
>
>
>
> R
>
>
> startsWith(str, pattern, trim=FALSE, ignore.case=FALSE)
>
>
>
> Scala
>
>
> startsWith[B](that: GenSeq[B], offset: Int): Boolean
>
>
> Golang, java, C++, Ruby, Swift have simples syntax, like
> string.startsWith(prefix)
>
>
>
> C#, Kotlin, R uses flag for ignore case.
>
>
> Anyway, I can't find language from various TOP-lists where present separate
> function for case insensitive operations.
>
>
> Another note - I see that many languages provide “start_index” parameter
> for
> start_with functions.
>
>
> So… As I say - this is good rfc in perspective, but more discussion is
> needed.

FTR, there is already `substr_compare()`.

Thanks,
Christoph

---

## #106172 — Claude Pache — 2019-07-08T13:53:47+00:00

URL: https://externals.io/message/106169#106172

> Le 8 juil. 2019 à 15:20, Christoph M. Becker <cmbecker69@gmx.de> a écrit :
> 
> FTR, there is already `substr_compare()`.

`substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the substring:

     substr_compare('foobarbaz', 'foo', 0, 3) === 0
     strncmp('foobarbaz', 'foo', 3) === 0
     str_starts_with('foobarbaz', 'foo')

—Claude

---

## #106176 — Zeev Suraski — 2019-07-08T14:35:43+00:00

URL: https://externals.io/message/106169#106176

>
> > […]
> écrit :
> > […]
>
> `substr_compare()` (as well as `strncmp()` which I am currently using in
> lieu of `str_starts_with()`) forces you to provides the substring and the
> length of the substring, instead of just the substring:
>
>      substr_compare('foobarbaz', 'foo', 0, 3) === 0
>      strncmp('foobarbaz', 'foo', 3) === 0
>      str_starts_with('foobarbaz', 'foo')


Explaining my 'no' vote (I was quite undecided on it).

Generally, I think it's a Good Thing to have startsWith/endsWith functions
in PHP.  However, several things made me eventually vote 'no' on this
proposal at this point in time:

1.  I'm still hopeful that we would one day clean up the global namespace
by creating a new set of namespacecd functions that would be consistent in
naming, semantics and argument order.  It feels wrong to add more to the
mess right now...
2.  Unless I'm mistaken, these functions introduce a new kind of notation
for case insensitivity that we don't presently have in PHP (_ci()).  Maybe
it's a good option, but having a new 3rd or 4th notation feels wrong.
3.  Given one can relatively easily (if not as elegantly) use
 `substr_compare()` to implement startsWith()/endsWith(), the added value
doesn't appear to me to be worth the downsides.

Zeev

---

## #106179 — Andrey Andreev — 2019-07-08T16:52:41+00:00

URL: https://externals.io/message/106169#106179

Hi,


>
>
> > […]
>
> `substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the substring:
>
>      substr_compare('foobarbaz', 'foo', 0, 3) === 0
>      strncmp('foobarbaz', 'foo', 3) === 0
>      str_starts_with('foobarbaz', 'foo')
>

The existence of `substr_compare()` and `strncmp()` is also my main
motivation for voting No, though I also share Zeev's reasoning.

You're right that the 2 already existing functions are a bit less
convenient to use, but the RFC doesn't even try to make a case for
that, so how do we know this was even considered? While I'm not
against having more than one way of doing things, I do think we need a
compelling enough reason to add a third way of doing the same thing
and here we don't even have an attempt to convince us.

Cheers,
Andrey.

---

## #106204 — Claude Pache — 2019-07-10T10:20:10+00:00

URL: https://externals.io/message/106169#106204

> Le 8 juil. 2019 à 18:52, Andrey Andreev <narf@devilix.net> a écrit :
> 
> Hi,
> 
> 
> > […]
> 
> The existence of `substr_compare()` and `strncmp()` is also my main
> motivation for voting No, though I also share Zeev's reasoning.
> 
> You're right that the 2 already existing functions are a bit less
> convenient to use, but the RFC doesn't even try to make a case for
> that, so how do we know this was even considered? While I'm not
> against having more than one way of doing things, I do think we need a
> compelling enough reason to add a third way of doing the same thing
> and here we don't even have an attempt to convince us.
> 
> Cheers,
> Andrey.

The current existing solutions (using `substr()`, `strncmp()`, `substr_compare()`, `preg_match()` or whatever) are sufficient—and may even look elegant—if you use them once in a blue moon. But if you happen to use them frequently, you’ll find soon that they are cumbersome and error-prone compared to the prospective `str_starts_with()` and `str_ends_with()`. Concretely:

* Each time I write `strncmp($foo, "bar", 3) === 0`, I spend a few seconds to double-check the number of bytes in "bar".

* Not later than yesterday, I spent one minute in order to find why `substr_compare($file, ".css", -3) === 0` didn’t do what I meant. Note also that the alternative `substr($file, -3) === ".css"` suffers from the same issue, and that the alternative `preg_match('/\\.css$/', $file)` requires you to not forget to escape special characters.

Checking whether a string begins, respectively ends, with some substring is a relatively common task for some programmers. The issue is that, although they have already plenty of ways to do that, none of them is natural and all of them have issues.

But indeed, the RFC text fails to discuss the various existing alternatives and their downsides.

—Claude