@dnolen: got a patch almost ready for http://dev.clojure.org/jira/browse/CLJS-1700 and only now realized it was assigned to you. should I go ahead and provide the patch anyway?

@anmonteiro: go for it!

@dnolen: thanks, just attached the patch. pinging you here since I can’t double assign you 😉

@anmonteiro cool thanks

I'm just testing namespace aliases with latest commit and noticed this ns doesn't work anymore:

(ns metosin.core.async.debounce
  #?(:cljs (:require-macros [cljs.core.async.macros :as a]))
  (:require #?(:cljs [cljs.core.async :as a]
               :clj [clojure.core.async :as a])))

Is this is a known issue? Is it an issue, is using same alias for macros and regular requires valid? Should I create an issue?

@juhoteperi: first make it minimal to determine what’s actually going on

no reader conditionals please, no external tooling either

@juhoteperi: using the same alias for a macro ns and a runtime ns (when they are differently named), I’m pretty sure if that ever worked it was not intentional

so I would probably not consider that a real regression

still if there’s a simple way to recover that ok, if it clashes with the new enhancements - not going to support it

Hmm, okay. I'll create report with minimal code anyway to be sure

@juhoteperi: FWIW it’s also breaking for me with current master, and working fine in 1.9.89

But first I'll try to find a better way to write that which works

this is what I used:

(ns foo.core
  (:require-macros [cljs.core.async.macros :as a])
  (:require [cljs.core.async :as a]))

(let [c (a/chan)]
  (a/go-loop [foo (a/<! c)]))

sure but I don’t recall anything ever saying that would work

nor why people believed it should

I never did that myself since I never knew it worked

I also didn’t know this would work, also why I tried it just now by curiosity

I don't remember if I saw if somewhere or how I found it - but I have found it the easiest way to write cljc code using core.async

right so this is not a real problem as far as I am concerned

but if there’s a simple patch to recover the old behavior, this is what I’m OK with

but I would still consider this super low priority and completely unintended and undefined

FWIW this is the commit that broke it: https://github.com/clojure/clojurescript/commit/41a62bfd916208d30bf621aefba56c5dce031ce5

@juhoteperi: I attached a patch to JIRA, can you confirm it fixes your issue? http://dev.clojure.org/jira/browse/CLJS-1716