Open Iainmon opened 3 months ago
Thanks for the request, Iain! Some docs could help solidify your proposal here.
First some specific comments:
slice
is a private helper and not really part of the proposal? Otherwise, why would I need it?countOccurances
while we have count
?takeUntil
really needs some doc or examples :)But I have some high-level ones as well:
At times we talked about a package/mason module like StringUtil
. Especially take
and drop
sounds like they could be suitable for something like that. The reason I am not too keen on having them in the standard library is because what they do can be achieved with slicing (ignoring param
part for a second, which I see as lack of implementation):
myString.take(3) == myString[..2] == myString[0..#3] == myString[..<3]
myString.drop(3) == myString[3..]
Maybe methods instead of slicing is more self-documenting. I am not sure if I believe that, but even if so, I am not sure if it is enough of an advantage to be in the standard library (vs. a package/mason one).
I am against proc this(start, end)
. It is too much of a workaround for the lack of param ranges. Something like that could appear in an application if you want to, but even that feels like a bad practice to me, as it would lead to patterns like myString[3,5]
which is not really clear to me. Especially considering what you want that to perform is actually representable in the language via myString[3..5]
, albeit losing the paramness.
Depending on your need for compile-time processing, we could consider implementing bounded param ranges.
Thank you Engin. I think you are right and waiting for param ranges would be a better option. As for your questions,
count
in the docs :)del
, then returns the string up until that point.
I was using these for parsing param strings and found them quite useful. But after thinking about its, they do seem sort of application specific and strange. The slicing function is just normal slicing at compile time
Yeah, but this
is what you use for slicing, right. proc slice
is more of a helper? Unless I am missing what idx
could be used for.
I was using these for parsing param strings and found them quite useful. But after thinking about its, they do seem sort of application specific and strange.
I can see them being useful. And I wouldn't really call them strange. Those (and their non-param versions) could make a good StringUtil
package/mason module that we can grow further as more similar things come along.
Do these match things on non-param strings? IMO having param
versions of some string functions is a great idea. That said, I think (?) these are different from existing non-param string operations and so perhaps go into a StringUtil
or similar module.
Summary of Feature
Description: I have been doing some string parsing at compile time and want to suggest these functions to be included in the standard library. I will open a PR if they all look admissible.
Code Sample