The specific case I'm worried about is using inspect on a map and then using that result in something that is expected to be deterministic (like using it as a key in Redis).
I did a quick search on Github for Elixir repositories using inspect as to_string. I found 4 cases where inspect was used outside of generating user readable strings. That one is basically assuming that inspect(<array of strings>) will output valid javascript. If a long integer were in that list it would cause a javascript error (I don't know if that's prevented elsewhere in the code or not): https://github.com/commentingon/DeepDive_PlugAndCowboy/blob/1ad46dad51543f39de8f3914ea5fc2f7a5624e9a/step_6/templates/rooms.html.ex#L61 This one is probably fine because `plural` will be a string: https://github.com/phoenixframework/phoenix/blob/b9e4ae9f658108d1def9a32c27b06c318ae67a98/priv/templates/phoenix.gen.model/model.ex#L4 This one is interesting because it assumes that Code.eval(inspect(a)) == a, which brings up the question of whether we allow underscores in integers in our code? (Yes we do, so that's good): https://github.com/mkremins/alembic/blob/2ae459201220b63af083d0d54325af93afa877f1/lib/config.ex#L47 That one is over my head. I don't know enough about absinthe to quickly figure out whether it would be a problem. https://github.com/absinthe-graphql/absinthe/blob/43c27219d7f289baf4dae36b1a5596d0a2235072/lib/absinthe/type/built_ins/introspection.ex#L263 I completely agree that it is a bad practice to use inspect as to_string in deterministic situations. However, this would be a really really painful bug if someone were to use inspect(map_with_long_int) as a key in a datastore. All unit tests would likely pass because any new entries would reflect the new behavior, but in production existing entries would be orphaned and cause a pretty big fire (rolling back would also be a nightmare because new entries would then be orphaned with the old code). I'm in favor of it being the new default, but messaging must be very clear here and disabling it should be part of that messaging. On Mon, Jun 20, 2016 at 9:50 AM José Valim <[email protected]> wrote: > > I'm nervous about existing inspect abuse as a hacky to_string. > > What do you mean? > > > I could see someone using it and feeding the result into a hashing > function and this change would break such an implementation. > > Using something like this today is already broken in all kinds of ways > that I am not particularly concerned about it. :) > > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Mon, Jun 20, 2016 at 6:44 PM, Peter Hamilton <[email protected]> > wrote: > >> I'm nervous about existing inspect abuse as a hacky to_string. I could >> see someone using it and feeding the result into a hashing function and >> this change would break such an implementation. >> >> Being able to turn it off is probably sufficient. Would it make sense to >> turn it off at a global level? >> >> On Mon, Jun 20, 2016, 9:38 AM José Valim <[email protected]> >> wrote: >> >>> I like this proposal. I would even pick it is a default with an option >>> to turn it off. Does anyone else have feedback? :) >>> >>> >>> >>> *José Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Director of R&D >>> >>> On Tue, Jun 14, 2016 at 11:22 PM, Wojtek Mach <[email protected]> >>> wrote: >>> >>>> Hello everyone, >>>> >>>> It's very convenient to write down integer literals as e.g. 10_000_000 - >>>> much easier for humans to read. >>>> >>>> I was recently debugging some performance issues and I was working with >>>> this data in iex: >>>> >>>> [memory: 173978912, message_queue_len: 0, heap_size: 12834421, >>>> total_heap_size: 21747214, >>>> garbage_collection: [min_bin_vheap_size: 46422, min_heap_size: 233, >>>> fullsweep_after: 65535, minor_gcs: 2]] >>>> >>>> This data would be *much* more readable to me with digit separators: >>>> >>>> [memory: 173_978_912, message_queue_len: 0, heap_size: 12_834_421, >>>> total_heap_size: 21_747_214, >>>> garbage_collection: [min_bin_vheap_size: 46_422, min_heap_size: 233, >>>> fullsweep_after: 65_535, minor_gcs: 2]] >>>> >>>> It probably shouldn't be the default behavior for inspect/2, so I >>>> think this could only happen with one of: [pretty: true] , [pretty: >>>> :decimal]or perhaps something like [pretty_decimal: true]. >>>> >>>> Regards, >>>> Wojtek >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "elixir-lang-core" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/93f9f36d-f3f3-41f7-856b-c1422cd40026%40googlegroups.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/93f9f36d-f3f3-41f7-856b-c1422cd40026%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bd%2BsvetpUs_mC-VEnH3y9J6nFyXyuDQ1ixW6Wnu7zV%3DA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bd%2BsvetpUs_mC-VEnH3y9J6nFyXyuDQ1ixW6Wnu7zV%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnwVRt-Xj2ajecHcdDPcZbCt5FU50v1Ng6gHH%2BAsD%2BjJag%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnwVRt-Xj2ajecHcdDPcZbCt5FU50v1Ng6gHH%2BAsD%2BjJag%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . > > >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BBfRJ792%2BPo7AZkkzcNgi4wLKh08YWJ6mfuKFeNAdzsQ%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BBfRJ792%2BPo7AZkkzcNgi4wLKh08YWJ6mfuKFeNAdzsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnwqzfc3_53aQdcFrfwCKUTd2n%3DaF-CTy_e4bFGPHvxiBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
