Logs

Next dev-meeting

[Feature #14784] One-sided Comparable#clamp (with endless/startless ranges) (zverok)

Still needs some work, mainly wondering if the idea of moving this part of stdlib into core VM is acceptable or not. No semantic changes except speed improvement.
Ko1 will check the patch and will comment in Aug.

pattern matching
Matz: positive for the proposal itself, though we need to discuss many details
Matz: Pin var_ should be changed
Matz: one-liner is slightly negative
Matz: guard must be able to write in pattern
Akr: & pattern is needed: [self] + values can be avoided by a pattern: [A, 1, 1] => A & [1, 1]
ko1: want to write [] in pattern instead of ()
Mame: NoMatchingError is needed?
Usa: is it a good idea to call deconstruct implicitly? is it better to write deconstruct explicitly?
Mame: the result of deconstruct must be cached
Tarui: cant distinguish between Array and Struct

case [1, 2, 3]
in a, 2 => b, c
p a, b, cl
end

case [1, 2, 3]
in [a, 2 => b, c]
p a, b, c
end

case Struct(2, 3)
in a, 2=> b, c
p a, c #=> Struct, 3
end

obj = Just(foo);
Case obj
In Just(foo)
In Nothing
End

Case obj
In Maybe(nil)
In Maybe(foo)
End

Suggestion: include method parameters when generating an ArgumentError message. Nobu's patch in the issue provides functionality to make writing a ruby gem to provide this functionality possible.
`method_name` is true method name, not `callee`.
current implementation by nobu returns callee, so, change the implement to return true name. after then, discuss about the necessity of callee.

Please discuss the necessity of the flag and its name in the proposal.
Use --disable-jit and --disable=jit, because we can already use --disable=gems and --disable-gems

[Feature #12306] Implement String #blank? #present? and improve #strip and family to handle unicode (sam.saffron)

blank? Is not the best name, but acceptable (space_only? or something might be better)
present? Is not acceptable at all
matz will accept the feature itself of blank?, but hope another good name
TBW

[Feature #14915] Deprecate String#crypt, move implementation to string/crypt (jeremyevans0)

To remove String#crypt, we first need to remove the dependency to String#crypt of WEBrick. We first listen Eric Wong (WEBrick maintainer)’s opinion.
If Eric agrees with the removal in future, we then ask Jeremy to release compatibility-layer gem by 2.6. If the release is succeeded, we can deprecate the core method.
And finally, we will remove the core method in future, after Eric removed the dependency to String#crypt from WEBrick in any way.

Carry over: