Re: [elixir-core:11303] Multi-letter (uppercase) sigils
No change or deprecation. They will remain allowed only on lowercase (and
therefore limited).
On Mon, Mar 6, 2023 at 00:33 Ben Wilson wrote:
> 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 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 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
.
>>>
>>>
>>> --
>>>
>>> Regards,
>>> Bruce Tate
>>> CEO
>>>
>>>
>>>
>>>
>>> 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
Re: [elixir-core:11303] Multi-letter (uppercase) sigils
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 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 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
>>>
>>>
>>> .
>>>
>>
>>
>> --
>>
>> Regards,
>> Bruce Tate
>> CEO
>>
>>
>>
>>
>> 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
>>
