I love this idea. Removing the ambiguity will help with adoption as new
developers to the language are less confused. It also allows infinite
sigils to be available without stepping on each other. I'm not suggesting a
jump on making sigils for everything.
You made the subtle point of sigils possibly having a different
interpolation syntax. I like the side effect of reducing errors, but it
also creates another syntax to learn. I like languages requiring you to be
safer by default, but this isn't a security concern in many circumstances.
~D[#{year}-08-24]
~D[{{year}}-08-24]
In the SQL case, it makes sense, but does it for something like Date?
Changing the interpolation syntax saves a small class of errors in specific
circumstances but creates multiple ways to interpolate that lead to
confusion, IMO.
Cheers,
Amos King, CEO
<https://twitter.com/binarynoggin>
<https://www.facebook.com/BinaryNoggin/>
<https://www.instagram.com/binarynoggin/>
<https://www.linkedin.com/company/binary-noggin>
573-263-2278 a...@binarynoggin.com
Book a meeting <https://calendly.com/amos-king>
On Sat, Mar 4, 2023 at 2:15 AM José Valim <jose.va...@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-core+unsubscr...@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>
> .
>
--
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/CAJr6D4SSmUaeskPzDZL3sBfR%2B-q2Xj%2BfEcRdH%2BJyRb84y9Dy2w%40mail.gmail.com.
