On Jun 18, 8:49 am, Rich Hickey <richhic...@gmail.com> wrote: > Fixing it requires adopting a single > semantic for +. Choosing auto-promotion precludes the use of + on > primitives, a huge loss IMO. Choosing throw-on-overflow precludes auto- > promotion, but preserves polymorphism otherwise, and gives the > compiler free reign to optimize since it will never be altering the > semantics by doing so. > > I don't see a way around this fundamental dichotomy. The semantics for > + should be unified, and the operator that makes the other choice > needs to be called something else, or placed somewhere else.
I'm just a newbie here, but I would prefer the simpler and faster + (with throw-on-overflow). I don't want to annotate my arguments (carefully!) to get primitive performance. I want the best performance in the simple cases. The primitive domain is big enough for most programs. I would be willing to use separate function names ("auto-promo-+", etc.) to get the "safe" auto-promotion semantics. Perhaps they could be in a separate namespace so that you can make your + symbol refer to the auto-promoting one if you want to pay the cost. By the way, I also want to know if a library is using auto-promotion so that I can avoid it unless I really need it. And, yes, I think I'll know enough about my domain to make that decision. Steve Miner -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en