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 <benwilson...@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-core+unsubscr...@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/CAGnRm4%2BsY%3DB_5YMMTz_ffkfQ%3DZykBCg5K_HZit4bwnghHfTeqw%40mail.gmail.com.
