Asymmetry between list.find and string/bytes.find/rfind

[jabraham17]

I noticed the following asymmetry between list.find and string/bytes.find/rfind

proc list.find(x: eltType, start: int=0, end: int=-1): int

string.find(pattern: string, indices: range(?) = this.byteIndices:range(byteIndex)): byteIndex
string.rfind(pattern: string, indices: range(?) = this.byteIndices:range(byteIndex)): byteIndex

bytes.find(pattern: bytes, indices: range(?) = this.indices) : int
bytes.rfind(pattern: bytes, indices: range(?) = this.indices) : int

I find it very odd and asymmetrical that list.find takes a start and end index, while string/bytes.find/rfind takes a range. The range argument feels much more Chapel-tastic and like a better interface; I think list.find should be updated to use that. Doing so is a breaking change, but I think its worth doing

[bradcray]

I'm also in favor of this. Would there be any ambiguity in providing both forms of both to avoid the need to break existing programs? (the obvious downside being "two very similar ways to say the same thing, one of which we probably prefer").

[jabraham17]

I think we could have both for now, but I haven't decided if that is more or less confusing

[bradcray]

I probably wouldn't add the int-based one to bytes/string, but could imagine adding the range-based one to list to improve the symmetry without removing the old one for a time.

[lydia-duncan]

Given that our adjustment to use ranges in the IO module (for the region argument) resulted in only having the range argument version, I think it would be reasonable to also take that tactic here.