<p dir="ltr">Likely though it'd probably be nicer to add atoms to the definition or create a new type.</p>
<p dir="ltr">I created a patch for iolist_to_binary and iolist_size and was looking at ports and files next but was wondering how practical it was more generally.</p>
<div class="gmail_quote">On May 25, 2015 14:07, "Fred Hebert" <<a href="mailto:mononcqc@ferd.ca">mononcqc@ferd.ca</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 05/25, Richard Carlsson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, I think it was a mistake not to include atoms in iolists to begin with<br>
(funnily, filenames can be deep and include atoms, but iolists can't). It<br>
might be pretty hard to change though, since there is so much existing code<br>
that might crash if it stumbled over an atom in a list that was produced by<br>
more modern code.<br>
<br>
Several functions in the standard libraries become needlessly expensive<br>
because of this need to expand atoms before they can be included in<br>
iolists, even when the result is just going to be sent directly to a file<br>
or port.<br>
<br>
</blockquote></div>
I would have expected it more reasonable to remove atoms from these than to add them everywhere.<div class="elided-text"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></blockquote></div>