You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
from, e.g. Array#fill(value : T, from : Int, count : Int)
index, e.g. Array#[]=(index : Int, count : Int, value : T), String#delete_at(index : Int, count : Int)
Across those methods, these parameters always have the same meaning and, with the exception of #fill and Slice#[], the same semantics too, so IMO they should share the same name. This would also mean one less thing to remember in case named arguments are used.
My preference is start; it captures the meaning most accurately, and is already the most frequently used name among them. from is often paired with to but the latter is absent in these overloads (if it did appear, surely from..to ought to take care of such an overload), whereas index does not indicate where the subrange is actually picked.
For comparison, all the related overloads that accept a Range seem to consistently use range as the parameter name already.
The text was updated successfully, but these errors were encountered:
There are three different ways to name the start index parameter in a method that accepts a subrange:
Array#[](start : Int, count : Int)
,String#byte_slice(start : Int, count : Int)
Array#fill(value : T, from : Int, count : Int)
Array#[]=(index : Int, count : Int, value : T)
,String#delete_at(index : Int, count : Int)
Across those methods, these parameters always have the same meaning and, with the exception of
#fill
andSlice#[]
, the same semantics too, so IMO they should share the same name. This would also mean one less thing to remember in case named arguments are used.My preference is
start
; it captures the meaning most accurately, and is already the most frequently used name among them. from is often paired with to but the latter is absent in these overloads (if it did appear, surelyfrom..to
ought to take care of such an overload), whereas index does not indicate where the subrange is actually picked.For comparison, all the related overloads that accept a
Range
seem to consistently userange
as the parameter name already.The text was updated successfully, but these errors were encountered: