vote on the equivalent http://ask.clojure.org page

okay

as we move past 1.12 we'll look through ask questions in vote ranked order

damn, okay lol

https://ask.clojure.org/index.php/questions/clojure?sort=votes

you'll notice a lot of those on that first page are closed or in 1.12

me and my single votes probably won't make it into consideration any time soon then lol

insert "there are dozens of us" meme

feel free to raise a list here too, I'm happy to take a skim for a 1.13 candidate list

sure, thank you

here you go, a list of tickets with less than 5 votes that to my eyes seem relatively easy to fix: • https://ask.clojure.org/index.php/1169/keyword-implements-collection-argument-produces-intuitive • https://ask.clojure.org/index.php/1931/docstrings-assoc-should-suggest-using-return-effect-always • https://ask.clojure.org/index.php/3325/make-foo-bar-baz-unreadable • https://ask.clojure.org/index.php/3774/test-line-reporting-doesnt-always-report-tests-file-number • https://ask.clojure.org/index.php/13539/classcastexception-when-misplacing-nth-args • https://ask.clojure.org/index.php/13605/number-reported-exceptions-thrown-generated-destructuring Some low votes that might be harder to merge but I think are helpful: • https://ask.clojure.org/index.php/12576/defrecord-should-efficiently-implement-ireduceinit • https://ask.clojure.org/index.php/12576/defrecord-should-efficiently-implement-ireduceinit and then 2 with 8 votes that i personally like: • https://ask.clojure.org/index.php/2370/make-conj-assoc-dissoc-transient-versions-handle-similarly • http://clojure.java.io/pushback-reader

we looked at the last two in 1.12 and pushed out. the last one especially is just such a mess in the impl differences it's way more than it appears. The refer one has been looked at by Rich and he keeps pushing it out (really this one is unobviously related to the serialized require issue). I'll look through the others

the first adds another slow condition check to every kw invocation so that's probably a non-starter unless the check gets moved to an error branch

the conj!/assoc! docstring got through screening all the way to Rich and I think he wanted some kind of wording change that was waiting on me to do, I don't seem to have a note about what though

I added some of the others to the 1.13 list

thank you, that's very kind of you

there are dozens of usAnother unit in the dozen Can't vote for • https://ask.clojure.org/index.php/1169/keyword-implements-collection-argument-produces-intuitive • https://ask.clojure.org/index.php/3325/make-foo-bar-baz-unreadable Because seems to be a breaking change. I don't want breaking changes in clojure. AND I think that these issues are fixed by #clj-kondo and other tools. But voted (some of them were already voted)

Rich's comment on the conclusion for unrolled assoc is interesting https://ask.clojure.org/index.php/3330/unroll-assoc-and-assoc-for-small-numbers-of-arguments https://clojure.atlassian.net/browse/CLJ-1656 Is it possible to make varargs faster? Is it possible to make them as fast as unrolled code? The real kicker would be defn level support for unrolled varargs Sort of like scheme's syntax-case Anyhow, would be happy if this issue could get some love.

A couple of your links seem wrong @UEENNMX0T : • https://ask.clojure.org/index.php/3334/improve-refer-performance • https://ask.clojure.org/index.php/1957/clojure-java-io-pushback-reader

oops, thanks. i should have double checked before posting!

I upvoted ones that might impact me (and downvoted a couple that would potentially break existing code -- I agree with @U2J4FRT2T on those). And saw that I'd already upvoted a couple of them previously so, yeah, love to see those considered 🙂

I didn't realize folks could downvote, I don't think I have that privilege

I've been bitten by the keyword/symbol one before but maybe that ship has sailed (there's a test in core for halt-when that fails if this is changed). The unreadable symbols one feels the same as enforcing :require in ns forms to me. It's buggy undocumented behavior and it shouldn't have been allowed to begin with.

There have been attempts to tighten up keyword reading in the past but they have turned up much more widespread usage of "invalid" keyword literals than expected... so I'm very wary of making that an error.

As for (sym x y) being a lookup that returns y, is that actually undefined behavior? It seems the behavior is very well defined and, as you say, has at least one core test that depends on it -- plus you may find it is depended on in the wild too. The code behind that lookup explicitly returns nil (or the not found value) when the first argument is not a lookup type...

> Is it possible to make varargs faster? Is it possible to make them as fast as unrolled code? we've done some poking on this and think the answer is maybe - going to dig in more on next release

Yeah, I won't defend the ilookup one. The error is annoying (and in a different world where it's enforced from the start, no one would bat an eye), but you are correct that it's consistent with the rest of the language and it's too great a change to make now

I think syntax errors should be errors and bugs in what determines what is a syntax error shouldn't be left alone merely because they made it past code review. That people rely on :1 or :foo/bar/baz is unfortunate but outside the purview of bug fixes; it's not just undefined, it's explicitly stated as not allowed by all documentation.

Trying to make :1 an error was what broke several widely-used libraries as I recall...

Re: varargs, any solution that will involve allocation on call (all rest args allocate an ArraySeq, no?) will always be slower than unrolled code Maybe it would be possible using a multiple arity definline (not hard, I think I have on in clj-fast), then a recursive definition would naturally expand to the unrolled version

(It was done in an alpha and reverted in the next alpha, several releases back)

this would also not violate the model of compilation unit being a single form