As I'm generally against case sensitivity I'm a big fan of Str.equalsIgnoreCase(...) - but the fact it is not null safe has just caught me out.

Currently Str.equalsIgnoreCase() takes a non-nullable Str which means it can not be used as a drop in (case-insensitive) replacement for equals().

Should it be nullable to remain consistent with equals()?

"str".equals(null)           // --> false
"str".equalsIgnoreCase(null) // --> NullErr thrown... Ouch!

Well my preference would be to keep it non-nullable. It is designed to operate on Str and equals only operates on null because it can compare different types.

A proper nullable version of equalsIgnoreCase should have Obj? parameter, and operate as equals everywhere except on Str. But that seems a bit contrived.

equalsIgnoreCase is not really like equals. It is a Str only comparison with a slightly misleading name.

I agree with @tomcl, its not really apples to apples. By convention you should really be using == to test equality and it has special handling for nullable on either side. You can't really do that when calling an OO method on a string. So I think its best left as non-nullable

FWIW Java equalsIgnoreCase accepts returns false for null on the RHS. Obviously it doesn't accept null on the LHS.

I guess that throwing NullErr is of little use here. It's just to remind you at runtime that nulls are evil.

OTOH it's more symmetrical, as it tests "is this non-null Str equal to that non-null Str"?

Fair point, as @Tomcl says, I guess equalsIgnoreCase() is not really comparable to equals() cos it only operates on Str.

throwing NullErr is of little use here.

Yeah, I did wonder if equalsIgnoreCase() in it's own right should accept null because it only returns true or false... but then you could argue that for any method that return a Bool; which wouldn't be right.

to remind you at runtime that nulls are evil.

Exactly, so I think the right answer is for me to check my code and ponder if I should have a null in the first place!