I found this proposal while reading Wojtek's proposal for URI inspect format
<https://groups.google.com/g/elixir-lang-core/c/OfDAYOu1gCU/m/SquHmQunCQAJ>
and wanted to resurrect it since it doesn't seem like anything had been
explicitly decided on.
In my opinion, this proposal is in line with sigils D, N, U, T: they are
not strictly necessary, but allow ergonomic creation of a built-in data
type with compile-time validation as well as a recognizable inspection
format.
One concern I initially had was that this might be a slippery slope that
could lead to many additional sigils, but it looks like URI and Version may
be the only remaining built-ins that don't have a "data literal" format
(either through an explicit literal or a sigil).
On Thursday, May 18, 2023 at 10:33:10 AM UTC-4 José Valim wrote:
> Uppercase sigils do not supported interpolation, so that's a no-go.
>
> Note you can also get the compile time behaviour today by doing @uri
> URI.new!("...").
>
> On Thu, May 18, 2023 at 4:25 PM Ben Wilson <benwil...@gmail.com> wrote:
>
>> Question: Would this sigil support interpolation? Is that too clever?
>>
>> ~URI"https://#{path}?#{query_params}";
>>
>> - Ben
>>
>> On Thursday, May 18, 2023 at 1:37:37 AM UTC-4 christ...@gmail.com wrote:
>>
>>> I dislike +1 posts, but I feel very strongly about this—it'd be amazing
>>> to have.
>>>
>>> I want booting an application to fail as fast and obviously as possible
>>> if someone gives it a bad phoenix host url, ecto database url, rabbitMQ
>>> url, redis url, mongodb url, etc. Preferably, before the connection is
>>> attempted; which, depending on the library in question consuming the url,
>>> often fails with a confusing network-failure-related error message.
>>> On Tuesday, May 16, 2023 at 7:51:21 PM UTC-4 Kip wrote:
>>>
>>>> I think this is a good proposal, as is the ~UTC one. Both make the
>>>> intent much clearer.
>>>>
>>>> On 16 May 2023, at 6:45 pm, Wojtek Mach <woj...@wojtekmach.pl> wrote:
>>>>
>>>> I just realised another small benefit of showing the full URL in the
>>>> sigil. Here’s a snippet from the proposal as rendered by my e-mail client:
>>>>
>>>> <PastedGraphic-1.png>
>>>>
>>>>
>>>> The URL was automatically made clickable. Tools like Livebook could
>>>> potentially do the same.
>>>>
>>>> On 16 May 2023, at 10:38, Wojtek Mach <woj...@wojtekmach.pl> wrote:
>>>>
>>>> Hi, I'd like to propose adding ~URI for constructing URI structs.
>>>> Here's an example:
>>>>
>>>> iex> ~URI"https://elixir-lang.org";
>>>> %URI{
>>>> scheme: "https",
>>>> authority: "elixir-lang.org",
>>>> userinfo: nil,
>>>> host: "elixir-lang.org",
>>>> port: 443,
>>>> path: nil,
>>>> query: nil,
>>>> fragment: nil
>>>> }
>>>>
>>>> I believe the advantage is we can make this a macro and thus parse the
>>>> URI string at compile-time
>>>> so catch bugs because of incorrect format early (though these are
>>>> pretty uncommon) and also be a
>>>> little bit more efficient at runtime.
>>>>
>>>> If added, I'm not sure whether ~URI should use URI.parse or URI.new!
>>>> under the hood so an advice
>>>> on that would be appreciated.
>>>>
>>>> This is a separate but related discussion so while at it, I'd like to
>>>> propose adding Inspect
>>>> implementation for URI that would return the sigil:
>>>>
>>>> iex> ~URI"https://elixir-lang.org";
>>>> ~URI"https://elixir-lang.org";
>>>>
>>>> I think more compact representation helps e.g. here. Before:
>>>>
>>>> iex> Req.new(url: "https://elixir-lang.org";)
>>>> %Req.Request{
>>>> method: :get,
>>>> url: %URI{
>>>> scheme: "https",
>>>> authority: "elixir-lang.org",
>>>> userinfo: nil,
>>>> host: "elixir-lang.org",
>>>> port: 443,
>>>> path: nil,
>>>> query: nil,
>>>> fragment: nil
>>>> },
>>>> headers: [],
>>>> body: nil,
>>>> options: %{},
>>>> ...
>>>> }
>>>>
>>>> After:
>>>>
>>>> iex> Req.new(url: "https://elixir-lang.org";)
>>>> %Req.Request{
>>>> method: :get,
>>>> url: ~URI"https://elixir-lang.org";,
>>>> headers: [],
>>>> body: nil,
>>>> options: %{},
>>>> ...
>>>> }
>>>>
>>>> On the other hand, seeing the internal representation right away is
>>>> sometimes useful given the URI
>>>> format is somewhat subtle.
>>>>
>>>> Before:
>>>>
>>>> iex> URI.parse("/foo")
>>>> %URI{
>>>> scheme: nil,
>>>> userinfo: nil,
>>>> host: nil,
>>>> port: nil,
>>>> path: "/foo",
>>>> query: nil,
>>>> fragment: nil
>>>> }
>>>> iex> URI.parse("//foo")
>>>> %URI{
>>>> scheme: nil,
>>>> authority: "foo",
>>>> userinfo: nil,
>>>> host: "foo",
>>>> port: nil,
>>>> path: nil,
>>>> query: nil,
>>>> fragment: nil
>>>> }
>>>>
>>>> After:
>>>>
>>>> iex> URI.parse("/foo")
>>>> ~URI"/foo"
>>>> iex> URI.parse("//foo")
>>>> ~URI"//foo"
>>>>
>>>> I think this downside can be alleviated by adding `IEx.Info`
>>>> implementation along these lines:
>>>>
>>>> iex> i URI.parse("/foo")
>>>> Term
>>>> ~URI"/foo"
>>>> Data type
>>>> URI
>>>> Raw representation
>>>> %URI{
>>>> scheme: nil,
>>>> userinfo: nil,
>>>> host: nil,
>>>> port: nil,
>>>> path: "/foo",
>>>> query: nil,
>>>> fragment: nil
>>>> }
>>>>
>>>> --
>>>> 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/9cc29c5e-ca64-42b3-83f8-84c60985efedn%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/9cc29c5e-ca64-42b3-83f8-84c60985efedn%40googlegroups.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-co...@googlegroups.com.
>>>>
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/elixir-lang-core/5D183EE3-56B8-41BB-8D23-5014C72EA0BE%40wojtekmach.pl
>>>>
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/5D183EE3-56B8-41BB-8D23-5014C72EA0BE%40wojtekmach.pl?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-co...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/6d4b45e2-31d4-45e5-927a-84fd3143902fn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/6d4b45e2-31d4-45e5-927a-84fd3143902fn%40googlegroups.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/04c08d34-926f-4f56-bbd4-348616beae68n%40googlegroups.com.
