Knowing nothing about this, it seems like making transients iterable would make it possible without changes to RT. But not sure if that would be a good idea or not.

expanding the scope of what transients are capable of is generally a bad direction

if you're passing transients to code that isn't aware of them, that's almost certainly a design error

things you can do to various transients: update them (conj! / assoc! / pop! / disj! ) graduate them (persistent!) get (get / lookup) count them

Yeah, my understanding of transient/persistent is that the scope has always been intended to be very minimal

I was disappointed the other day that I couldn't update one 🙂

same deal as with empty? -- you can update them with your own function

but ya can't pass them to generic code that isn't aware of transients

Yeah, my first reaction was "Aww!" and then I was like, "No, that makes perfect sense..." and I just assoc!'d in an updated value 🙂

After nine years of using Clojure, I don't question core decisions anywhere near as much as I used to 🙂

update! should be easily writable though

17 lines of code with ! added in the appropriate places 🙂 But each of those functions add up. And I only needed a specific arity (and it's the first time I've wanted update! in all those years).

@jimmy yes, i wrote that on the ticket

the options seem to be implement iterable or cond in empty? to do the (zero? (count coll)) for TransientCollections. Mike fikes has proposed the latter on the CLJS side.

this is a bad idea devin

empty? == (not (seq )) transients aren't seqs

Are Arrays?

are arrays what?

(seq (java.util.ArrayList. [1 2]))

transients are designed to have a limited amount of operations to work on them

seq isn't one of them

user=> (seq (transient []))
Execution error (IllegalArgumentException) at user/eval143 (REPL:1).
Don't know how to create ISeq from: clojure.lang.PersistentVector$TransientVector

I'm well aware

(i think it's a bad idea to make empty? work on transients in clojurescript as well)

(I think this issue is distinct from the issue of contains? being broken on transients - https://dev.clojure.org/jira/browse/CLJ-700 , as find already works on transients, so why shouldn't contains?)

empty? has a particular implementation, fwiw, and I don't see it changing

Yes, this is a separate issue. That is also noted on the empty? ticket.

I guess I mean it's different in nature: one is a busted impl, one is enlarging the contract of transient

https://dev.clojure.org/jira/browse/CLJ-1872 ticket is here if you're interested in adding your opinion. The short list of operations supported on transients makes sense, sure. You can add and remove things, get a value at a position, check for the existence of a value or values across vec/set/map, count them. All those fun things. Truth of the matter is I don't necessarily disagree with you, but I found myself at the contains? issue while poking around in JIRA today, and then found my way over to this ticket. The ticket is currently listed as a defect with critical priority. It was triaged and vetted. Were it not for these things, I may not have spent any time looking at it.

A bounded-count would be fine on lazy sequences

Seems reasonable to me to check whether the transient you're dealing with is empty.

I forgot about bounded-count

it already works on transients too

I'm not sure I follow. Transients are counted?, and so bounded-count simply calls count on the transient.

@devn I think that was just in response to the comment about not being able to define empty? in terms of count because of potentially infinite lazy sequences...?

(so it could be defined in terms of bounded-count)

ah, I see.