Fork me on GitHub
#clj-kondo
<
2020-06-09
>
eskos09:06:08

I was reading this https://clojuredocs.org/clojure.core/keyword#example-542692d3c026201cdc326fde and had a thought to test this out, and seems clj-kondo doesn’t warn about these non-conformant keywords. Should it/could it?

borkdude09:06:34

@suomi.esko can you give a concrete example that doesn't require me to read this entire page?

eskos10:06:53

Hmm, the anchor link doesn’t work for you? There’s a list of non-conformant keywords, eg. (keyword "abc def") (keyword "") (keyword "...") and one I’ve actually seen in production, (keyword ":a")

borkdude10:06:25

the link works, but I don't have time to read all this, so if you can condense your question that would be helpful. clj-kondo can check those kinds of things, but in general the argument to keyword are runtime values, not literal strings - this is something which clj-kondo cannot check

eskos10:06:46

That’s the could/should part. I’m not really sure why Clojure hasn’t natively spec’d that part, since it’s quite easy to make all kinds of mangled garble with the keyword function.

borkdude10:06:42

this topic has come up often in the #clojure channel. I think one of the problems with narrowing down the possible keys is that it would break existing code which clojure will never do

borkdude10:06:16

you can always write your own my-keyword function that checks things. one other reason is performance. creating keywords should be very fast in clojure. additional checks will mean a performance penalty

dominicm10:06:21

In the future these things will maybe be made valid too

borkdude10:06:29

@U09LZR36F in which context do you mean valid? is anything invalid right now?

dominicm10:06:19

Well, :1 isn't valid right now, but it works in some places

dominicm10:06:21

I guess what I really mean is that Alex has hinted that (keyword "foo bar") will eventually print in such a way that it can be (read-string)

borkdude10:06:25

interesting, I wonder how they're going to do that

dominicm10:06:59

It was hinted that the syntax would be something like :|foo bar|

dominicm10:06:07

and | would ergo be the only restricted character.

borkdude10:06:07

:"foo" could also work

dominicm10:06:31

Yeah, I recall the pipe character being mentioned explicitly

borkdude10:06:27

so tl;dr: clj-kondo isn't going to do anything about this 🙂

dominicm10:06:00

I think this was the conversation

dominicm11:06:36

Nope, a separate one 😁

dominicm11:06:07

I'm bored of searching now, I swear there was a | syntax though

dominicm11:06:14

maybe specifically for symbols? Dunno

dominicm11:06:01

symbols was the key term

dominicm11:06:59

@U04V15CAJ fwiw, I think the specific typo of (keyword ":ANYTHING") might be worth catching

dominicm11:06:06

(having reflected on it for all of 30s)

dominicm11:06:23

Nothing broad, just catching the silly mistake of putting : when using the function

borkdude11:06:47

wouldn't that also be valid in the future with :|:foo|?

dominicm13:06:25

Yeah, I suppose it would :)

eskos14:06:32

I’m willing to bet that pipe surrounded form will break backwards compatibility even worse though… 🙂

dominicm14:06:06

I doubt it. Besides, anyone relying on that is relying on something that was never promised.

borkdude14:06:32

I think the Clojure on DotNet has special syntax which uses this. It will break them