Issue #13576 has been updated by Eregon (Benoit Daloze).


This could break methods which take a pathname-like object and call #to_path when a File is passed to them (e.g. File.delete(file), etc).
I am not saying it is good practice, but I think it should be evaluated for compatibility.

Maybe it's just easier to return nil for to_path on that case, just like File#path?

----------------------------------------
Bug #13576: File#to_path shall be deleted
https://bugs.ruby-lang.org/issues/13576#change-65054

* Author: shyouhei (Shyouhei Urabe)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
[Feature #13568] sheds light on situations where a File might not have its corresponding path.  I understand that this is a nature of a file in general, that it might or might not have such thing.  I don't argue that fact.

Problem is however, that ruby's File class has its to_path method.  The to_path method is used internally _right before calling open()_.  The intention is clear that the return value of to_path must be something meaningful as an argument to that function.  This is impossible for a O_TEMPFILE -created file descriptor, because such file can never be opened again.

So in general, calling to_path over a File instance is a mistake.  Let's not do it.



-- 
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>