If I remember correctlry ~s is already optimising with the no-interpolation case? If yes I’d rather use ~s mor all possible cases and use ~S to signal that the string contains something that looks like interpolating or escapes, but are not.
lud
0
mudasobwa
Creator of Cure
How on the Earth it might have been optimized? Feel free to compare to sigil_S/2 implementation.
There is no democracy here, sorry 
In other checks provided by this library sigil_S/2 is blindly accepted as an argument to raw/1 and family, and sigil_s/2 is alerted. First implementation (that is now ditched) had examined all the sigil_s/2 content to decide whether to alert or not, based on the actual interpolation presense. That is slow and not transparent for the user.
1
lud
Well it’s a macro, it compiles to a binary, here is no additional runtime cost to ~s if there is no interpolation.
0
mudasobwa
Creator of Cure
What? I provided the link above. Here is the code itself:
defmacro sigil_s({:<<>>, _, [piece]}, []) when is_binary(piece) do
:elixir_interpolation.unescape_string(piece)
end
The aforementioned :elixir_interpolation.unescape_string/1 is defined here: elixir/lib/elixir/src/elixir_interpolation.erl at v1.19.5 · elixir-lang/elixir · GitHub
I would not copy its implementation here, because it consists of 124 LoCs, including subcalls and extensive pattern-matching.
That said, no, the runtime cost for long strings (walked through in a sophisticated unicode-aware manner) might be huge.
0
lud
I’m not sure we are talking about the same thing:
defmodule X do
def foo(x) do
[
~s"x is #{inspect(x)}",
~s"some static string"
]
end
end
The BEAM decompiles to this Erlang code:
-module('Elixir.X').
-compile([no_auto_import]).
-export(['__info__'/1, foo/1]).
%% __info__ redacted
foo(_x@1) ->
[<<"x is ", ('Elixir.Kernel':inspect(_x@1))/binary>>,
<<"some static string">>].
To me it’s clear that <<"some static string">> is a compile time static value generated by ~s so my humble opinion is that it’s better to stick to ~s for most cases except for escaping concerns. Though I’m not saying it is the one true choice, I can just disable this specific rule anyway.
Edit: or your are specifically targetting compilation time, in that case the rule makes sense. I disagree because in our codebases ~s (and sigils in general) are pretty rare, and it’s better to signal escaping concerns with uppercase sigils while paying a very tiny time cost for it. But the other way is valid too.
0
mudasobwa
Creator of Cure
Yes, I meant compile time, of course, since Elixir compiles down to Erlang forms and those have no such thing as “string interpolation.” It does not actually matter, if a sigil is a macro or not, because it’s nevertheless not only expanded, but also applied during compilation phase (and it gets expanded to the funciton anyway.)
in our codebases
~s(and sigils in general) are pretty rare
Then it does not matter to your codebases at all. All code analysis tools, though, including but not limited to oeditus_credo, will treat the difference between ~s and ~S sigils strictly per documentation, thinking that ~s is dynamic and should be alerted if used in suspicious context.
0
lud
You said the runtime cost for long strings […] might be huge (whereas it is zero) but you meant compile time, of course :p.
Anyway, I don’t see the documentation discouraging lowercase sigils when there is no interpolation. But I agree my team could use a cultural shift where we would default to ~S in most cases indeed.
Also, I could be nice to support something like Well it’s a credo wrapper so it’s all in there.--ignore-test-files when using with mix archive.install, wdyt? Maybe it’s already there but I did not find it after a quick docs scan.
0
adamu
Are you interested in this one? Probably doesn’t fit, but might as well ask
1
mudasobwa
Creator of Cure
I might be interested in this one, if it becomes less opinionated (I love sigils, fwiw.)
Namely, I would encourage using the same style, configured through config, let the default be your verbose one. If you don’t mind providing a PR, I am all in to merge it.
1
dimitarvp
For what it’s worth, I prefer explicit lists as well. Especially the ~w(one two three)a I always viewed as confusing. But nowadays I stopped using the bare w() form as well.
1