Project

General

Profile

Feature #15523

Let `Range#begin` and `Range#end` be aliases of Range#first and Range#last

Added by sawa (Tsuyoshi Sawada) 6 months ago. Updated 6 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:91010]

Description

My understanding is that Range#begin and Range#end's features are just subsets of Range#first and Range#last, respectively. And since they are slightly confusing with the keywords begin and end, I propose to either:

  • Let Range#begin and Range#end be aliases of Range#first and Range#last, respectively, or
  • Let Range#begin and Range#end be obsolete after a migration path of waning against their use and recommending the use of Range#first and Range#last instead.

History

Updated by sawa (Tsuyoshi Sawada) 6 months ago

Sorry, please change this to a feature request instead of a bug report.

Updated by kou (Kouhei Sutou) 6 months ago

  • Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN)
  • Tracker changed from Bug to Feature

Done.

Updated by shevegen (Robert A. Heiler) 6 months ago

I have no particular pro or con opinion towards this proposal per se; however within
the two suggestions made, I think having these as aliases would be better than
obsolete them. People could then decide to use either variant if they would like
to whereas with the second suggestion they may have to forego the use of
begin/end as method names. Note that I understand the intent behind the
deprecation thought, but I think it would still be better for ruby folks to decide
on their own what they would prefer. Not everyone is necessarily confused,
although I understand that it may be confusing for some.

(But again, I do not have any particular strong pro or con opinion as such. I actually
think that I may not have used #first or #last on Range so far in my own code
altogether; neither #begin or #end).

Updated by mame (Yusuke Endoh) 6 months ago

Objection.

I understand that "your problem" is confusion between a keyword "begin" and "Range#begin". First, I have never been confused by the fact. Then,

  • Let Range#begin and Range#end be aliases of Range#first and Range#last, respectively, or

This does not solve your problem at all.

  • Let Range#begin and Range#end be obsolete after a migration path of waning against their use and recommending the use of Range#first and Range#last instead.

Your problem looks too weak to me to deprecate an existing feature.

Off-topic: Could you please make the title informative? "Range#begin and Range#end" doesn't tell me what is a problem or proposal. I never say this to a newbie, but you have already opened hundreds of tickets.

Updated by mrkn (Kenta Murata) 6 months ago

sawa (Tsuyoshi Sawada) Please tell us how can we get both the end-value of the exclude-end range and the last element of the sequence generated by the range if your proposal were accepted?

Updated by mrkn (Kenta Murata) 6 months ago

sawa (Tsuyoshi Sawada) Sorry, please don't mind my previous comment. I confused the behavior of Range and one of ArithmeticSequence.

#7

Updated by sawa (Tsuyoshi Sawada) 6 months ago

  • Subject changed from `Range#begin` and `Range#end` to Let `Range#begin` and `Range#end` be aliases of Range#first and Range#last

Updated by sawa (Tsuyoshi Sawada) 6 months ago

mame (Yusuke Endoh) wrote:

I understand that "your problem" is confusion between a keyword "begin" and "Range#begin". First, I have never been confused by the fact. Then,

Actually, that was a minor point (I, myself, have not been confused that much. Although I do not like the way it looks to have begin and end used as methods).

By proposing:

  • Let Range#begin and Range#end be aliases of Range#first and Range#last, respectively, or

My real intent was that, I don't see any reason for Range#begin and Range#end to be separate methods from Range#first and Range#last. If people are indeed going to use Range#begin and Range#end, then letting them take an optional argument (just like Range#first and Range#last) would make it simple for everyone.

Also available in: Atom PDF