into-array should not need type hints

Question

Currently into-array's return value needs type hinting in addition to having to specify the target class in the first place. Type hinting array types isn't exactly trivial either (with the weird and extremely verbose ^"[Lorg.clojure.MyClass;" syntax).

It would be really nice if the compiler could deal with that for the user.

Answer 1

Could you give an example?

Comments

Here is one that I have scattered about in various projects running in our production environments, it's to facilitate interop with a Java library that does db migrations (Flyway)

<pre>
;; When you work with arrays in Clojure (and wish to avail of performance
;; improvements by using type hinting) you have to make sure that the type of
;; the array is known to the compiler. The type hints for primitive arrays are
;; ^longs, ^chars, ^doubles, etc.; for arrays of objects you have to use an
;; unwieldy construct like ^"[Ljava.lang.String;"

(defn ^:private flyway
  ^Flyway
  [datasource migration-locations]
  (Flyway. (doto ^FluentConfiguration
             (FluentConfiguration.)
             (.dataSource datasource)
             (.locations ^"[Ljava.lang.String;" (into-array String migration-locations)))))
</pre>

---

You don't usually need a type hint for something like this (because arity is sufficient to resolve). This particular method has overloads for String[] and Location[] though. I'm not disagreeing with your original request, just trying to clarify the cases where it matters.

I don't think it's easy to do this right now without more compiler level support.

---

The ones I ran into recently:
* netty Http2ServerUpgradeCodec constructor (Http2FrameCodec, ChannelHandler...)
* netty ApplicationProtocolConfig constructor (Protocol, SelectorFailureBehavior, SelectedListenerFailureBehavior, String...)
* netty SslContextBuilder/forServer (PrivateKey, String, X509Certificate...)

---

@valerauko are those varargs methods?

---

Yes (although that's only one case of array overloading, same issue would occur for other array overloads).

Answer 2

Logged as https://clojure.atlassian.net/browse/CLJ-2631