Issue #12050 has been updated by Thomas Enebo.


Usaku NAKAMURA wrote:
> Nobuyoshi Nakada wrote:
> > Eliminating all ambiguities is not always convenient, I think.
> 
> The convenience is derived from your knowledge about the implementation.
> For others who are not familiar with the implementation, the behavior is unpredictable.
> The unpredictability may cause undesirable troubles.
> 
> Note that I don't talking about `--dump` option because it's for debugging the interpreter,
> and the debugger should know well about the implementation :-)

I agree with you.  For impl-specific options it is arguable whether ambiguity is important, but once enable/disable ends up with a potential ambiguous short-hand someone will end up getting confused.

The first feature encountered eliminates this ambiguity but I think most people would not expect this heuristic and they would expect an error on ambiguous entry.  Of course, that is just one opinion :)  Also, perhaps there will never be enough enable/disable options where they are ambiguous features.



----------------------------------------
Bug #12050: Should feature processing really accept any substring of the feature name?
https://bugs.ruby-lang.org/issues/12050#change-56921

* Author: Thomas Enebo
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
ruby --disable-gems -e 1
ruby --disable-gem -e 1
ruby --disable-ge -e 1
ruby --disable-g -e 1

I found this because in test_syntax.rb someone used --disable-gem and JRuby is currently doing matches on the full feature name and erroring otherwise.  If this is intentional it means no two features should ever start with the same letter...



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>