RFCs icon indicating copy to clipboard operation
RFCs copied to clipboard

Make `substr*(a: openArray[char])` consistent with other overloads

Open ZoomRmc opened this issue 9 months ago • 0 comments

Abstract

Currently there's a considerable semantic discrepancy between substr overloads:

proc substr(s: openArray[char]): string
proc substr(s: string; first = 0): string
proc substr(s: string; first, last: int): string 

Motivation

No response

Description

The first one is different in signature and behaviour:

  1. It does not perform any substringing operations, relying on a previous openArray construction call. In its current form this proc only creates a new string, which is a straight implementation of #14810
  2. It does not perform input index validation/clamping, in contrast to other overloads

Proposal: I claim that in fact, the first variant should be renamed to toString/toOwned/copy/etc. and a new susbstr overload with consistent behaviour (clamping) should be added:

proc substr(s: openArray[char]; first = 0; last = s.high()): string

This proc is already implemented in proc substr(s: string; first, last: int): string and the latter becomes just a call of the former.

This will result in consistent and predictable behaviour and would close #14810, allowing to stop reimplementing it multiple times in such places as unicode or re.

Code Examples

No response

Backwards Compatibility

Replacing proc substr(s: openArray[char]): string with an overload with default parameters might change the behaviour of some code relying on the current proc not clamping, but it's hard to predict the scope. Introducing PR #20527 is about 2.5 years old but I'm not sure if it's widely used already.

ZoomRmc avatar Mar 25 '25 14:03 ZoomRmc