Yup. Elixir is explicit about imports by design, with Kernel being the single exception. You will need to define some sort of MyProject.Kernel and import it wherever you want to use its functions.

Just BTW, the is_nil/1 function does not choose is_nil over nil? half-hazardly, this is in line with a particular Elixir naming convention:

Type checks and other boolean checks that are allowed in guard clauses are named with an is_ prefix.

Note that type checks that are not valid in guard clauses do not follow this convention. For example: Keyword.keyword?/1.

To follow this convention that other developers in your project may rely upon, you would either want to name this function empty?/1, or implement it as a guard.

That implementation will be different than the functional version, but can be used anywhere guards or allowed! To translate your example is_empty/1, it would look something like:

defmodule MyProject.Kernel do
  defguard is_empty(thing) when thing in ["", nil, []]
end

Finally, as a design note, outside of extenuating circumstances, I would treat it as a code smell that you are often checking if thing in ["", nil, []]. The implication is that you are regularly uncertain if your data is a string, list, or null value; all throughout your program.

It would be hard with no context to diagnose why this is happening or propose a better pattern, but I would keep on this part of your code! You may find an opportunity to coerce the variable type of an input into your program into a known single type close to where it is received, then confidently refactor a lot of less-confident, unassertive code. Then theoretically you could handle “empty cases” throughout just by matching against one of "", [], or nil.

There’s nothing automatically imported besides Kernel in elixir. You either need to import explicitly or have a macro doing the import.

I’ve dealt with this a few times also in some legacy codebases and the best solution I found is to use custom Ecto types that know how to deal with these values, you skip the step where you have to deal manually with these kind of checks.

That’s a very common situation, makes perfect sense!

Generally, rather than scattering these checks across my codebase, I’d try to exert them within modules singly responsible for interacting with ecto structs that have these quirks—for example, perhaps inside the schema modules themselves with changesets, or a context module that validates and navigates all of this conditional logic in one place.

Specific to this common empty-string data-model case however, I’d propose a simpler way to handle this—at least, if your team is willing to make a schema change, and using postgres—other dbs may have similar solutions but I’m not sure:

ALTER TABLE thing ADD CHECK (field <> '');

This simply ensures that a given field can not be an empty string.

Whether or not my text fields are NOT NULL these days, I simply do not allow empty strings in my data model. It never makes sense in the domain layer, causes semantic confusion in nullable columns, and as you experience, pushes a whole bevy of edge case handling to application logic.

Empty strings are the opposite of data, moreso than NULLs! Get’em out of your database! Make invalid states unrepresentable! Have your nullable changesets cast "" to nil once, your non-nullable ones error, and never think about it again.

The one exception is maybe if I have a user-entered free-form text area like a description and I want to discern between “never interacted with” and “had a value manually deleted”. But that’s really something that should be modeled differently, with change tracking or an enum-type state machine.

Edit: I just noticed your mention that

Feel free to ignore my rant against empty strings, then! If your team finds signal in them, by all means normalize in the application layer rather than the data model! @D4no0 's suggestion is a great one.

You’re a missing a guard here.