So in elixir sometimes you need to do something like this:
def function(acc, condition1, condition2) do
acc <>
cond do
condition1 -> "hello"
condition2 -> "world!"
true -> "" # Add nothing to acc
end
end
Sometimes you need to use an empty string. Currently i only see two options for that
using "" (empty string with two double qoutes)
using <<>> (empty binary)
It would be a good thing if Elixir’s String module would provide a function like: String.empty/0 that would return a human readable form of empty string in Elixir.
But for now, Which way you think is better to use? 1 or 2? Or any other solutions?
I personally think that 2 is better since no special chars can hide inside it!
I’m not sure if we really need String.empty/0. Thats very noisy and writing the empty string literally saves me a lot of keystrokes.
And if one should use "" vs. <<>>, well it depends. If I am dealing with String (meaning a sequence of unicode characters) I do prefer "" while I prefer to use <<>> when I am dealing with random binary garbdata.
As string combining ({"", &<>/2}) forms a Monoid (Just like:
{0, &+/2},
{1, &*/2},
{false, &Kernel.||/2}
{[], &++/2},
{%{}, &Map.merge/2},
{MapSet.new(), &MapSet.union/2}
et cetera…
) , both String.empty/0 and String.append/2 would be wonderful functions to have, making this behaviour more explicit .
By that argumentation we also need Integer.one/0, Integer,zero/0, Integer.multiply/2, Integer.plus/2, List.empty/0, List.append/2, Map.empty/0, et cetera.
Monoids are true in elixir as they are in haskell, but not such a big thing. Also the monoid just works, regardles of using String.empty/0 or "".
I have to admit, sometimes one wants to/has to pass a function which returns the neutral of a monoid and since writing &("") or &""/1 isn’t possible, we have to use fn -> "" end, but that cases are so rare, that I do not think that there is really a benefit of adding such functions.
There are UTF-8 chars that are not visible. Like half space in Arabic and etc. Since i write code with Persian strings in it, there is a common mistake that i press alt+Space that generates a half space which is not visible.
Here is an ordinary double quote → ""
Here is a half space between two double quotes → ""
Can you tell which one is the real empty one?
This problem is not affecting integers or list nor any other data type.[quote=“NobbZ, post:7, topic:6203”]
Also I have jsut discovered that there has been a PR closed by José:
[/quote]
If this is a widespread problem, then we need to make sure those chars show up when inspected by default, rather than adding functions that return pre-built strings.
He suggested to tackle this issue by using a good string inspection that shows these things.
You diodn’t got whom I answered That was in direct resonse to @Qqwy comment about beeing {"", &<>/2} a monoid.
But in general, I think you are right, invisible characters are indeed a problem, but in my opinion, they are not a problem of a language. They are a problem of your editor and the display engine used therein.
Just consider C, they don’t have a function which creates an empty string, but can run into even worse trouble than we could when there are random invisible characters in their strings when they don’t expect them.
I’m seeking an atom package that shows whitespaces.
I just ran into this issue yesterday and it was frustrating to find out about that whitespace in my string.
Since i was a .NET developer before Elixir and back there it has string.Empty constant i thought maybe it’s a good idea here too.
But since that whitespace can happen in any other strings force showing them in editor will be a good idea. And since there are not lots of people using a keyboard with this kind of layout adding String.empty/0 does not make sense.
I was able to nearly convience some co-students of mine to take a closer look at elixir last year, when I showed them a talk about HTTP2-Parsing via binary-pattern-matching. Finally they have then been scared away by the word “functional”. Our introductionary course uses haskell and sadly it scares people away from functional programming instead of luring them