私は次を提案します。

 まず、 slice/slice! については

	alias slice []		# []と等価

	def slice!(*args)	# 削除しつつ削除したものを返す。
	  a = self[*args]
	  self[*args] = []
	  a
	end

でいいです。delete関連については、二つ考えました。

A案)ちょっと保守的な案

	def delete_range(range)	# 特に何も返さない。
	  self[range] = []
	end

	def delete_at(i)	# 現状のまま。削除した要素を返す。
	  if 0 <= i && i < self.size
	    e = self[i]
	    self[i] = []
	    e
	  else
	    nil
	  end
	end

	def delete_from(i, len)	# 特に何も返さない。
	  if 0 <= i && i < self.size
	    self[i, len] = []
	  end
	end


 単純に英語の語法として delete_at(i, len) と delete_at(range) は
ちょっと抵抗を覚えます。もし delete_at という名前のメソッドを残し
たいなら、 at, from, range ときっぱり分けた方がいいと思います。

 なお、効率のため、範囲削除の際に削除された部分を返すのは無駄だと
思います。slice! があるので。

B案)ちょっと革新的な案

	delete(e)		eに一致する最初のものを削除
				(現状と同じ)

	delete!(i)		i番目を削除
				(現状の delete_at と同じ)

	delete!(i, len)		i番目からlen個を削除
				(A案の delete_from と同じ)

	delete!(n..m)		n番目からm番目を削除
				(A案の delete_range と同じ)

	delete! {|x|...}	ブロックの評価値が真のものを削除
				(現状の delete_if と同じ)

 Ruby の設計思想として同名のメソッドが signature の違いによって
振る舞いを変えるというのは好ましくない、というのがあったと思うので、
これはちょっと暴挙かも。(それほどまでに delete_at(range) が嫌って
こと?)

 ただ、意味は明白なのであながち捨てたものではないかもしれません。

	Q.なぜ delete(e) に比して delete! メソッドが破壊的か?

	A.delete(e) の場合は、配列から削除したいオブジェクトを
	    削除する側が持っているので復元が可能だが、 delete! には
	    そういう前提が成り立たないから。また、すでに delete_if の
	    別名である reject! に ! が付いている。


 私としては、B案を第一希望、A案を第二希望としたいです。

 どうでしょうか。

-- 
                     /
                    /__  __
                   / )  )  ) )  /  http://www.idaemons.org/knu/
Akinori MUSHA aka / (_ /  ( (__(   mailto:knu / idaemons.org

"We are but hungry..  Associated Ita-meshi Daemons!"
                                   http://www.idaemons.org/