I'm generally +1 on this, but I am a tiny bit confused about the proposed change to interpolation. Does this propose a change to interpolation for all sigils, single or multi letter? If so, what is the deprecation plan for the current interpolation syntaxx?
On Sunday, March 5, 2023 at 2:21:47 PM UTC-5 José Valim wrote: > This has been accepted and merged. Thanks everyone. > > On Sun, Mar 5, 2023 at 4:12 PM Bruce Tate <br...@grox.io> wrote: > >> This change would be a most welcome one. Sigils are going to be more >> important as Elixir expands into new domains, and it's helpful to have >> clues to what each sigil does. >> >> The restrictions to upper case seem to be reasonable ones. >> >> -bt >> >> On Sat, Mar 4, 2023 at 3:15 AM José Valim <jose....@dashbit.co> wrote: >> >>> Sigils in Elixir are currently limited to a single letter. We had many >>> discussions in the past about allowing more letters but they were >>> ultimately rejected because of lowercase sigils. >>> >>> The issue with multi-letter lowercase sigils is that: >>> >>> 1. they are ambiguous to humans >>> 2. they are ambiguous to machines >>> 3. they may have security implications >>> >>> For instance, I would say that sigils in Elixir have quite distinctive >>> features: >>> >>> var = ~w"foo" >>> var = ~w[bar] >>> >>> Tilde, a letter, and the content surrounded by terminators. However, >>> given how most identifiers in the language are lowercase, I think using a >>> multi-letter starts to become less clear. For example, imagine we supported >>> a sigil named opts: >>> >>> var = ~opts[bar] >>> >>> That's awfully close to: >>> >>> var =~ opts[bar] >>> >>> Which would in fact be ambiguous at the parser level. >>> >>> The other aspect is that security recommendations suggest different >>> interpolations to be used for different aspects. For example, imagine >>> someone wants to implement a SQL query sigil that automatically escapes >>> characters. Today, one could write this: >>> >>> ~q""" >>> SELECT * FROM posts WHERE id = #{id} >>> """ >>> >>> And that would be safe! But the fact we are using interpolation means >>> someone can simply forget the ~q at the front and write an _unsafe_ query. >>> It would be much better if the interpolation is different altogether: >>> >>> ~SQL""" >>> SELECT * FROM posts WHERE id = {{id}} >>> """ >>> >>> On one hand, it may feel inconsistent to have different ways to >>> interpolate, but at the same time it is reasonable to use different >>> mechanisms when different behaviours and security trade-offs are involved. >>> Especially because #{...} typically means string conversion and that's not >>> the case for SQL queries (it is simply parameter placement). >>> >>> With all of this in mind, the suggestion is to allow only multi-letter >>> uppercase sigils. Most sigils are uppercase anyway: >>> >>> 1. Elixir defines 4 lowercase sigils (~r, ~s, ~w, and ~c) but 8 >>> uppercase ones (the four previous plus ~T, ~D, ~N, ~U for datetimes) >>> 2. Nx uses ~V and ~M for vectors and matrices respectively >>> 3. LiveView uses ~H, Surface uses ~F, and LiveView Native will need at >>> least two uppercase sigils for Swift UI and Jetpack Compose >>> >>> Therefore, I would like to propose for multi-letter uppercase only >>> sigils to be introduced and be, from now on, the recommendation for new >>> libraries. This means we won't deprecate ~T, ~D, ~N, ~U in Elixir, but >>> there is still time to rewrite ~V and ~M in Nx to ~VEC and ~MAT. LiveView >>> and Surface can decide if they want to migrate or not, ~SF may be a better >>> choice for the latter, but LiveView Native can choose to support, for >>> example, between ~JETPACK or ~JC if it prefers an abbreviation. >>> >>> Looking forward to feedback, >>> >>> >>> >>> -- >>> 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 elixir-lang-co...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KTx%2BYW02gQLvH-ihyhgv6dAhjrwSEdhP81niuvjrWfTg%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KTx%2BYW02gQLvH-ihyhgv6dAhjrwSEdhP81niuvjrWfTg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> Regards, >> Bruce Tate >> CEO >> >> >> <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97> >> >> Groxio, LLC. >> 512.799.9366 <(512)%20799-9366> >> br...@grox.io >> grox.io >> >> -- >> 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 elixir-lang-co...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-6_r_vqo6ccXHT79JQO1RdaLOwdanfSqN7VsxZRWACm_g%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-6_r_vqo6ccXHT79JQO1RdaLOwdanfSqN7VsxZRWACm_g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/574a7a1b-0f50-4497-8592-a41034e6db4fn%40googlegroups.com.