Escaping in sigil_w

~w because it is a list or words. "foo bar" is not a word it doesn’t fit semantically

I like to think of these sigils as a way to communicate intent to the reader (the list should only be made up of single string tokens) rather than a shorthand for the writer. I never use the a modifier for this reason, as well as others.

I just never use them. It doesn’t take much effort to write out a list, and it’s completely unambiguous when read - which is many more times than written.

My point is we are not always in control of the contents of these lists. Things like paths names or spreadsheet headers can easily contain spaces, and whenever this occurs the sigil needs to be replaced by traditional lists. I would love to avoid that by being able to escape whitespace.

That’s my point, though: if it’s only incidental that the entries are single words and could be more, I don’t bother using the sigil version. I understand the pain, though.

sigil_w and it’s uppercase counterpart are macros. Their values need to be compile time known.

This is not the tool to use for user input or anything you don’t know what it is.

No the contents are static, but out of our control.

You’re still free to use a more appropriate tool to parse content you cannot make sure is going to be a list of words. These sigils really are conveniences for when you’re dealing with a list of words and you don’t want to type that much. You’re not dealing with a list of words as it seems, so you want to use something else.

I am dealing with lists. E.g. in the case of paths, the System.cmd() function accepts a list of arguments, often containing pathnames. I could give other examples, but trust me I have encountered it enough to warrant this post. Even using a variable doesn’t work:

foo_bar = "foo bar"
~w[#{foo_bar} baz]
=> ["foo", "bar", "baz"]

A list of words is a subset ot all list. You’re clearly not dealing with just that subset.

If you’re dealing with CLI arguments OptionParser might be the more appropriate tool to use.