Changed label name for string functions to sub.

[bschommer]

As mentioned by @dbuenzli in #9533 (comment) using sub as label might be a better idea since it is uniform across all functions and would allow higher order usage of the function. Since the functions in questions are not yet officially released so we still can change them. I don't think this needs a changelog entry for this.

[dra27]

I apologise for coming armed with a paint can, but "sub" is an English abbreviation for "substitute" which makes these functions read very strangely to me (I grant that it's consistent with String.sub, but that's a more ancient piece of history which to me only reads OK because I very rarely open String so it just reads like substring backwards...).

Can I offer either ~substr (which I still don't like for a function which is about prefix/suffix) or - given that includes/mem was discussed previously, ~affix which actually covers all of those uses?

[xavierleroy]

but "sub" is an English abbreviation for "substitute"

Or for submissive, subliminal, subscriber, submarine (sandwich), subwoofer, subtitle, or subutex, according to the Urban Dictionary...

Can I offer either ~substr (which I still don't like for a function which is about prefix/suffix)

Indeed, I think "sub" was intended to connote "substring", not "substitution".

or - given that includes/mem was discussed previously, ~affix which actually covers all of those uses?

I've never seen "affix" used in ordinary speech, in programming, nor in computer science textbooks.

The original code with "prefix" and "suffix" is fine. Let's not make it worse.

[dra27]

Can I offer either ~substr (which I still don't like for a function which is about prefix/suffix)

Indeed, I think "sub" was intended to connote "substring", not "substitution".

My point is it reads oddly to use a word meaning substitute (I'll see your Urban dictionary and raise you the OED...) as an abbreviation for a different word... although at least we've never come close to the JavaScript meaning of String.sub!

or - given that includes/mem was discussed previously, ~affix which actually covers all of those uses?

I've never seen "affix" used in ordinary speech, in programming, nor in computer science textbooks.

Erm, for what it's worth - I learned it in computer science, possibly, according to Google, in exactly these slides: https://www.cl.cam.ac.uk/teaching/2004/NatLangProc/slides2.pdf

The original code with "prefix" and "suffix" is fine. Let's not make it worse.

I agree - although there was a higher order argument for using the same label name.

[dbuenzli]

I have used affix in some of my designs but I was never really happy about it.

Now I think one day we want do want to have String.includes if only to be able to mirror String.contains in the UTF-8 interpretation of OCaml strings. That day we'll need a label for the substring being searched. I think sub is a good one for this one and, by extension for these two other functions.

The notion of substring is a pretty well established concept, we already have String.sub and I'll certainly add String.find_sub add some point. I don't think there's any potential for confusion when you read the functions applied in context.

[dbuenzli]

(I would gladly link on the sub- prefix entry of https://dictionary.cambridge.org/, but it seems their redesign broke basic www functionality)

[xavierleroy]

The notion of substring is a pretty well established concept, we already have String.sub

As @dra27 wrote, String.sub works because it reads automatically as "substring".

and I'll certainly add String.find_sub add some point.

To me find_sub reads as "find substitute [teacher]" or "find [something kinkier from the Urban dictionary list]", not "find substring". For that you'd need find_substr or find_substring.

[dbuenzli]

To me find_sub reads as "find substitute [teacher]" or "find [something kinkier from the Urban dictionary list]", not "find substring". For that you'd need find_substr or find_substring.

I wouldn't have thought the latin sub prefix would be interpreted so wildly in a programming context.

In any case you won't find these things unprefixed or as single tokens, in context this is String.find_sub ~sub s which reads ok to me and is inline with Strings.sub s pos l.

But if we really need not to hurt anyone's interpretation and/or trigger perverted minds, I'm fine with using substr. However let's be consistent and name that concept throughout the API this way, not with a different name in each of its occurrences. That would mean:

String.includes : substr:string -> string -> bool
String.starts_with : substr:string -> string -> bool 
String.ends_with : substr:string -> string -> bool
String.find_substr : ?start:int -> substr:string -> string -> int option 
String.sub : string -> int -> int -> string (* that one we can't change *)

For reference that's what a simple sub would look:

String.includes : sub:string -> string -> bool
String.starts_with : sub:string -> string -> bool 
String.ends_with : sub:string -> string -> bool
String.find_sub : ?start:int -> sub:string -> string -> int option 
String.sub : int -> int -> string -> string 

[bschommer]

I changed the label from sub to substr. However if there is no consensus I can also life with the old names.

[dbuenzli]

I still think sub is a better name. People should stop seing these things in isolation and write some code with the functions. In context I personally do not find it ambiguous and there are yet other functions I would like to add like String.subrange which further establish a context for String in which the three letters sub stand as being the sub- latin prefix.

[dbuenzli]

Also a native english speaker actually did propose to use sub here.

[bschommer]

As in the original PR it seems that there is no conclusion what a good name would be, so I close this PR.

[gasche]

I would also be in favor of sub which is shorter (good!) and reads just fine to me personally. I don't think that it is common to write code with the String module opened non-locally, so the String name that reassures people on the meaning of sub will be around anyway. Also the hair-splitting around affix suggests that trying to find a different label name for variants of the same notion is bound to create more pain down the road.