x:y is parsed as string instead of function

[fkz]

Well, I'm not sure how it should be parsed, but I just spend quite some debugging time to find out that nix parses x:x not as the identity function but as the string "x:x"; so we appearantly have to always put a space after a :.
This may be a good coding convention, but then I'd like x:y to error. If this is there to allow uris, maybe we can match for :// instead of just :

[lucabrunox]

It's indeed unexpected to be a string. But I guess changing this would require a nix 2.0?

[vcunat]

The parsing is documented to follow RFC 2396 URIs which do allow schemes without //. We might change this on a major nix bump to get more intuitive, but certainly not just to some ad-hoc rule...

[fkz]

Interesting. But RFC2396 even allows the following URI (if I've correctly read the BNF): a:;
and nix isn't accepting it. Pretty much everything else it seems though.
hm, I guess we have to let it be like this then.

[Ericson2314]

Is there any reason for the current special parsing of URIs? With parsing paths, I get that the purpose is resolving relative paths, but that doesn't make sense for URIs. Maybe in the major version bump we can just remove it :).

[vcunat]

Well, yes, it's not very useful currently. It saves you quoting around the URL but in exchange you can't anti-quote, so I often (have to) use the quotes anyway.

[copumpkin]

I'd be in favor of killing unquoted URLs in some upcoming language revision :) the fewer special cases in the language, the happier I am

On Mar 9, 2016, at 15:04, Vladimír Čunát notifications@github.com wrote:

Well, yes, it's not very useful. It saves you quoting around the URL but in exchange you can't anti-quote, so I often (have to) use the quotes anyway.

—
Reply to this email directly or view it on GitHub.

[Ericson2314]

We can always add a nixpkgs lib function or builtin to validate URIs if the need arises too.

[edolstra]

The reason why we have special parsing of URIs is because Nix is a DSL for describing packages, and packages descriptions almost always contain URIs, so it's convenient to have some special syntax for them.

[domenkozar]

But I wonder what value that really gives us? I haven't seen much usage from having them as special type.

[abbradar]

One idea: forbid general URIs and instead require all of them to have //. I imagine this would help with problems like this one and #1017 and also don't break too much code.

[Ericson2314]

I suppose that's better than status quo, but I'd really like to get rid if it all together. Could we put it to a vote or something?

[stale]

I marked this as stale due to inactivity. → More info

[stale]

I closed this issue due to inactivity. → More info