https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112014-10-27T09:35:10ZRuby Issue Tracking SystemRuby master - Feature #8848: Syntax for binary stringshttps://bugs.ruby-lang.org/issues/8848?journal_id=496612014-10-27T09:35:10Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-4 priority-default" href="/issues/10391">Feature #10391</a>: Provide %eISO-8859-1'string \xAA literal' string literals with explicit encoding</i> added</li></ul> Ruby master - Feature #8848: Syntax for binary stringshttps://bugs.ruby-lang.org/issues/8848?journal_id=496652014-10-27T18:43:05Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:duerst@it.aoyama.ac.jp" class="email">duerst@it.aoyama.ac.jp</a> wrote:</p>
<blockquote>
<p>One reason for this efficiency. String#b creates a duplicate object,<br>
which is not at all necessary for the frequent use case of String<br>
literals.</p>
</blockquote>
<p>Avoiding one allocation is easy to add to [Feature <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: [PATCH] opt_str_lit*: avoid literal string allocations (Open)" href="https://bugs.ruby-lang.org/issues/10423">#10423</a>]<br>
(which avoids string literal allocations for many methods)</p>
<blockquote>
<p>Another reason is encoding validity. To be able to e.g. create a<br>
"\xFF" binary string, with String#b in an UTF-8 source context, it is<br>
necessary to allow "\xFF" (temporarily at least) as an (actually<br>
invalid) UTF-8 string. This may be difficult for some implementations,<br>
and isn't desirable in general.</p>
</blockquote>
<p>We can even go farther than <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: [PATCH] opt_str_lit*: avoid literal string allocations (Open)" href="https://bugs.ruby-lang.org/issues/10423">#10423</a> and move the evaluation of<br>
"string literal".{b,encode,force_encoding} to compile time.</p>
<p>The downside is compatibility with people who wish to override one of<br>
those methods, but doubt anybody overrides those...<br>
There's no new (and strange looking, IMHO) syntax to learn,<br>
it looks like a normal method call, and the optimization would be<br>
usable with existing code.</p> Ruby master - Feature #8848: Syntax for binary stringshttps://bugs.ruby-lang.org/issues/8848?journal_id=496762014-10-28T08:33:17Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>Eric Wong wrote:</p>
<blockquote>
<p>We can even go farther than <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: [PATCH] opt_str_lit*: avoid literal string allocations (Open)" href="https://bugs.ruby-lang.org/issues/10423">#10423</a> and move the evaluation of<br>
"string literal".{b,encode,force_encoding} to compile time.</p>
<p>The downside is compatibility with people who wish to override one of<br>
those methods, but doubt anybody overrides those...</p>
</blockquote>
<p>Even if nobody overrides String#encode, they may configure it in various ways.</p>
<blockquote>
<p>There's no new (and strange looking, IMHO) syntax to learn,<br>
it looks like a normal method call, and the optimization would be<br>
usable with existing code.</p>
</blockquote>
<p>It's not enough to move evaluation to compile time. We may want to know the desired encoding before we start to parse the string. That by definition doesn't work when the method (or whatever) comes after the end of the literal.</p> Ruby master - Feature #8848: Syntax for binary stringshttps://bugs.ruby-lang.org/issues/8848?journal_id=955742021-12-23T23:43:57Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Project</strong> changed from <i>14</i> to <i>Ruby master</i></li></ul>