But why?

$ irb
irb(main):001:0> require "yaml"
=> true
irb(main):002:0> puts({"foo" => nil}.to_yaml)
---
foo: 
=> nil

Crystal behaves like Ruby.

If you want, maybe that can be a configuration of a YAML::Builder. But I think this is too much. Empty is null in YAML, as was noted in the comments.

IMO ~ is more expressive - it is something instead of nothing and therefore alleviates confusion about the value type stored there - as seen in the linked issue.

Also, I believe it's not a big trade off in terms of size - just 1 character more for bit of clarity.

Maybe rename this to "Serialize nil as ~ in YAML". The current PR title really confused me.

Example in description would also help

This issue is about personal taste. No solution is better than the other.

My taste follows @asterite here. I prefer having nothing than ~ which I never saw before, despite using YAML for many 10+ years, and I would naively understand it as a "~" string (i.e. it's confusing).

Just to clarify (as I opened the related issue), that issue was mainly due to my lack of knowledge on how null could be represented in YAML. Coming from Python's PyYAML, I was used to seeing the word null for null values, but it turned out that this was only one of the many possible values that the YAML spec offers. i personally have never seen ~ until it was mentioned in that issue either, and I work with YAML heaps!

I personally believe the current behaviour is the most appropriate. Not only does it follow Ruby's style but also printing any nil value in Crystal prints empty output which makes the YAML behaviour consistent.

Users who want different behaviour can very easily patch this as follows:

struct Nil
  def to_yaml(yaml : YAML::Nodes::Builder)
    yaml.scalar "~"
  end
end

While I initially brought up the suggestions to use ~, I wouldn't recommend a change unless there is some real evidence for improvement.

The only (minor) case where a change might perhaps be useful is nil.to_yaml - currently it produces --- \n...n which looks a bit strange to people not familiar with the ... document end identifier. Here, a bit more expressiveness like --- \nnull\n...\n could be nice.

I would prefer null over ~ but I prefer `` over the other ones. I would just not recognize ~. Seems like the spec if flexible though on what can be used.

I believe we'll stick with the current behavior. Closing.