ずびしいず
hogefuga
reachabilty判定の導入によって改善されるもの
("b".."aa")
のような単純な辞書順比較によって正しく評価されていなかったrangeが正しく評価されるようになる
("b".."aa").to_a => []
になる問題もこれで解決できるRange#include?
String#upto
で全列挙していた実装の代わりに本methodを使うことで判定が高速に行えるようになる
("b".."aa").include?("z")
, ("b"..).include?("aa")
などの辞書順比較を用いていたことによるバグが直る
string contain with alunm(s)
"a" is reachable to "a", "z", "aa", "abc"
"b" is reachable to "z", "aa", "abc", unreachable to "a"
"0" is reachable to "9", 10", "10298"
"0" is unreachable to ":", "a", "0a"
"aa00" is reachalbe to "ab00", "abcasdfv84"
"." is reachable to "10982"
書くのめんどくせえ
string with no alunm
https://docs.google.com/presentation/d/156xZN9OrN6NPyof3E_1K-oOeCf0J-Hh8vtcuvoxjcto/edit?usp=sharing
上に関連して,Rubyについて,rangeの始端もしくは終端にUTF-8文字が含まれると非自明な挙動をする
("a".."あ").to_a #=> ["a", ... , "zzy", "zzz"]
[*"z".."aa"] #=> []
[*"a"..."z"] + [*"z".."aa"] == [*"a".."aa"]
になるのが自然だが、[*"z".."aa"]
が空になるためこれは一致しない(c..a)
のようなものにイテレーションを走らせないようにした結果,このように到達できるものもはじいてしまっている("aa"..).include?("b") #=> true
rubyのRange#include のstringが特殊なケースを除いてString#uptoを呼び出しているため遅い
rb_str_include_range_p@string.c
を呼び出すrb_str_upto_each
を呼び出している(0..1).include?(0.5) #=> true
String#succ のアルゴリズム
str_succ
enc_succ_alnum_char
を使うenc_succ_char
を使うenc_succ_alnum_char
max_gaps
によって定められる)enc_succ_char
enc_pred_char
enc_succ_char
の逆enum neighbor_char
NEIGHBOR_NOT_CHAR
NEIGHBOR_FOUND
NEIGHBOR_WRAPPED
enc_succ_alnum_char
だと「次が文字として無効だったから巻き戻せるところまで巻き戻したよ」みたいな意味enc_succ_char
だとバイト長が変わったみたいな意味?メモ
reachabilty判定の導入によって改善されるもの
("b".."aa")
のような単純な辞書順比較によって正しく評価されていなかったrangeが正しく評価されるようになる
("b".."aa").to_a => []
になる問題もこれで解決できるRange#include?
String#upto
で全列挙していた実装の代わりに本methodを使うことで判定が高速に行えるようになる ("b".."aa").include?("z")
, ("b"..).include?("aa")
などの辞書順比較を用いていたことによるバグが直るTODO
ascii_str_reachable_p
rb_str_upto_each
rb_str_include_range_p
range_include_internal
memo
bool RTEST(VALUE value)
("a"..).each{|c| p c}
rb_str_upto
およびこれのメインロジックに相当するrb_str_upto_each
とは別にendless用にrb_str_upto_endless_each
を用意している.String#upto
を使っているString#upto
の第一引数endに nil
を渡すことを許容する
__
prefixつきのメソッドをprivateとして実装しているものがあるためこれを踏襲する(使えてはしまうが)
__sub_replace@string.rb
など_
の数は1個だったり2個だったりする(え?)mrb_range_beg_len()@range.c
)mrb_range_beg_len()@range.c
)Range#to_s
, Range#inspect
nil.to_s
は空文字になるので結果的に Range#to_s
改変の必要はない('b'..'d').include?('ba')
の挙動が ruby と mruby で異なる問題がある // TODORange#{max, last}
Range
Array#[]
, Array#[]=
String#[] with Range
String#[]= with Range
がなかったので生やしたEnumerable#take
など各種メソッドMRB_WITHOUT_FLOAT
すると落ちる('b'..'d').include?('ba') # => true
("a".."あ").each{|e|p e}
rb_str_include_range_p@string.c
を呼び出すrb_str_upto_each
を呼び出している(9223372036854775807..9223372036854775808).each
が壊れるWITHOUT_FLOAT
でコンパイルが通らない
(TITLE) Introduce endless range. (a part of https://github.com/mruby/mruby/issues/5085)
We introduced endless range feature, which is proposed in https://github.com/mruby/mruby/issues/5085 and already supported by CRuby.
For other changes, please see the diff.
MRB_WITHOUT_FLOAT
environment, we implemented to return nil for now.––– PR下書きオワリ ––––––––––––––––-
MRB_WITHOUT_FLOAT
を定義してコンパイルすることで Float を排除できる
mrb_nil_p(a)
a.nil?
=
の位置を揃える場合と揃えない場合があるぞい//
は使わない、/* */
のみ使うRange.new
だけならnilチェックだけでいいだろうけど、``1..`のような場合)