[#109115] [Ruby master Misc#18891] Expand tabs in C code — "k0kubun (Takashi Kokubun)" <noreply@...>

Issue #18891 has been reported by k0kubun (Takashi Kokubun).

13 messages 2022/07/02

[#109118] [Ruby master Bug#18893] Don't redefine memcpy(3) — "alx (Alejandro Colomar)" <noreply@...>

Issue #18893 has been reported by alx (Alejandro Colomar).

11 messages 2022/07/02

[#109152] [Ruby master Bug#18899] Inconsistent argument handling in IO#set_encoding — "javanthropus (Jeremy Bopp)" <noreply@...>

Issue #18899 has been reported by javanthropus (Jeremy Bopp).

10 messages 2022/07/06

[#109193] [Ruby master Bug#18909] ARGF.readlines reads more than current file — "JohanJosefsson (Johan Josefsson)" <noreply@...>

Issue #18909 has been reported by JohanJosefsson (Johan Josefsson).

17 messages 2022/07/13

[#109196] [Ruby master Bug#18911] Process._fork hook point is not called when Process.daemon is used — "ivoanjo (Ivo Anjo)" <noreply@...>

Issue #18911 has been reported by ivoanjo (Ivo Anjo).

9 messages 2022/07/13

[#109201] [Ruby master Bug#18912] Build failure with macOS 13 (Ventura) Beta — "hsbt (Hiroshi SHIBATA)" <noreply@...>

Issue #18912 has been reported by hsbt (Hiroshi SHIBATA).

20 messages 2022/07/14

[#109206] [Ruby master Bug#18914] Segmentation fault during Ruby test suite execution — "jprokop (Jarek Prokop)" <noreply@...>

Issue #18914 has been reported by jprokop (Jarek Prokop).

8 messages 2022/07/14

[#109207] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedYet — Quintasan <noreply@...>

Issue #18915 has been reported by Quintasan (Michał Zając).

18 messages 2022/07/14

[#109260] [Ruby master Feature#18930] Officially deprecate class variables — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18930 has been reported by Eregon (Benoit Daloze).

21 messages 2022/07/20

[#109314] [Ruby master Bug#18938] Backport cf7d07570f50ef9c16007019afcff11ba6500d70 — "byroot (Jean Boussier)" <noreply@...>

Issue #18938 has been reported by byroot (Jean Boussier).

8 messages 2022/07/25

[#109371] [Ruby master Feature#18949] Deprecate and remove replicate and dummy encodings — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18949 has been reported by Eregon (Benoit Daloze).

35 messages 2022/07/29

[ruby-core:109344] [Ruby master Misc#18942] String splitting handling of empty fields is incorrect or insufficiently documented

From: "scub8040 (Saverio M.)" <noreply@...>
Date: 2022-07-27 18:42:07 UTC
List: ruby-core #109344
Issue #18942 has been updated by scub8040 (Saverio M.).


austin (Austin Ziegler) wrote in #note-1:
> scub8040 (Saverio M.) wrote:
> > There are other cases though, which I think are either incorrectly handled, or at least, they should documented.
> 
> This is neither a behaviour bug nor a documentation bug.

Uh, ok! Thanks.

----------------------------------------
Misc #18942: String splitting handling of empty fields is incorrect or insufficiently documented
https://bugs.ruby-lang.org/issues/18942#change-98486

* Author: scub8040 (Saverio M.)
* Status: Open
* Priority: Normal
----------------------------------------
Hello!

The string splitting needs to deal with some edge cases when it comes to empty strings/fields, for example, an emptry string always returns an empty array.

There are other cases though, which I think are either incorrectly handled, or at least, they should documented.

The main case is a string exclusively composed of separators, e.g.:

```
"|||".split "|" # => []
```

Semantically speaking, such splitting does make sense, as an empty field is still a field. As the above example shows though, this returns an empty array (following the explained logic, it should return 4 empty strings).

IMO, this is incorrect. If for any reason this isn't, this should be documented though, as it's not obvious behavior (I've referred to this page: https://ruby-doc.org/core-3.0.0/String.html#method-i-split).

Things get even more obscure, when there are non-empty fields:

```
"||a|".split "|" # => ["", "", "a"]
```

This result is definitely inconsistent with both logics explained above:

- if empty fields should be treated as effective fields, the function should return ["", "", "a", ""]
- if empty fields should be ignored, it should return ["a"]

Considering this second case, I think that the function is buggy; there's no reason to treat differently the empty fields on the left of a non-empty field, from the ones on the right.

Even if this behavior is considered correct, I think it's very valuable to document such cases, as they're not intuitive, especially the second.



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

In This Thread

Prev Next