(blank? nil) returns nil?

[lacarmen]

I really think the blank? function should be returning true when you pass it nil. The function ends with a ? which is an accepted convention for indicating a boolean return value. The behaviour is also inconsistent with clojure.string/blank? which returns true on nil.

[niwinz]

Hello @lacarmen. I think you are speaking about two things:

• The convention on ending the function name with ? indicates that is a predicate and should return a logical boolean. In this case, nil represents a logical false so it is correct output. In clojure everything except false and nil is a logical true.
• Cuerdas works with strings and treat them strongly, this means that nil can't be considered as a blank string. Yeah, this is inconsistent with clojure.string/blank?, but cuerdas does not have any intention to be consistent with it. In fact, cuerdas fixes an makes all functions (that are part of cuerdas) consistent and null pointer safe (every function that receives nil, will return nil).

[dustingetz]

Here, ceurdas is not just inconsistent with clojure.string/blank? but also inconsistent with clojure as a whole, which compensates for lack of type safety with the philosophy of nil-punning. Nil is monoid zero. This "fix" is a pretty frustrating opinion.

[niwinz]

Do yo have any suggestion for an improvement?

[dustingetz]

In my opinion, if you treat nil like mzero, all predicates can return bool instead of maybe-bool, which I believe is consistent with clojure.core. Absent that, adding blank-or-nil? is a helpful bandaid, otherwise the call sites have to be written as (or (nil? value) (str/blank? value))

[niwinz]

That i'm trying to do with that library is make it nil safe, treat nil as empty string in predicates and other functions can be dangerous (in that case nil not will be skiped, it will be processed as part of your logic, but empty string does not means absence of value, it means that it has empty string value...).

Cuerdas is a string library and works with strings, if you want treat nil as empty string in your logic does not means that ever user of this library should do it. As example, on my applications, i have strong separation between absence of value that empty string, so if i have values that can be string and nil, i'm explicitly check for that instead of making a supposition that the library will do it for me. Explicit better than implicit

Saying that, unless there are other much better rationale for treat nil as empty string, im going to stay with the current approach. However, I'm open to have helpers like blank-or-nil? in the library so please open a PR with new helpers.

[dustingetz]

I respect what you're trying to do and it makes sense from a perspective where you control every piece of code to distinguish between nil and "". The philosophy breaks when you interop with code written by other people, including all of javascript ecosystem, now I have to adapt their world into your world, and if I forget even a single spot, prod goes down.

[yogthos]

I share the concern @dustingetz raises. Since it's an accepted pattern to treatnil as falsy in Clojure, having blank? return nil for absence of value is highly error prone in practice. Since Clojure is already conflating nil and false, you have to do an explicit nil check if you care about absence of value anyways.

[niwinz]

@yogthos and don't you consider error prone returning true for something that is not blank?

[yogthos]

In cases where the distinction is important, you still have to do an explicit check. However, I think that returning true is better than returning a falsy value in practice. I'd also argue that this kind of data validation is better done outside the library in any case using Spec or Schema.

[dustingetz]

Setting my opinions on idioms aside for now, I see now the docs are bugged. My repl shows all cuerdas predicates return nil for nil input, but the docs show them returning bool. So that's just a docs bug and can be fixed, we do read your docs (which are great btw).

A prominent line like "Nil and "" are distinct in this library, all fns when passed nil will return nil (notably including predicates), use blank-or-nil? style of fns for this case"

Clojure.core has precedent for IllegalArgumentException, which at least helps me discover that I misunderstand the contract https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L1378-L1384

An interesting thought experiment is to consider where the blank? predicate is actually used:

(remove s/blank? ["asdf" " " "" nil])
     ;  ("asdf" nil)   
     ; nil has been collapsed to not-blank!

(defn remove (filter (complement pred)))
(defn complement ([x] (not (f x))))
(defn not [x] (if x false true))

So in the worldview under discussion, (remove s/blank?) would need to fail a typechecker or something to prevent broken behavior

[alehatsman]

yeah guys, I spend so much time figuring out what the fk going wrong in my code, and only today I realised that blank? returns nil for nil, you guys are fking gods of api design thank you

[JovanToroman]

I join in the opinion that blank? should return true for nil values. Can you please change it? This unintuitive decision harmed the good opinion that I had about your library pretty badly. Also, it took away a few hours of my life that I spent debugging (so it seems to behave as a bug) this issue. Otherwise, can you please provide the blank-or-nil? helper?

[niwinz]

I will reopen this issue and will make the change. I do not 100% agree with the reasons but the popular opinion counts here. So I will make the blank? return true for nil