Anchor map key with no space before colon works in v3; breaks in v4

[mikefarah]

Not sure if this is intentional in v4 - but this used to work in v3:

f:
  a: &a cat
  *a: b  # this specifically

Whereas v4 this no longer works - and you need a space between the anchor and colon

f:
  a: &a cat
  *a : b  # this will now work 

From what I understand the yaml standard was a little vague here - and tools like yamllint also do not like *a: blah - I'm happy enough to update the test in yq because I think this is fairly niche if anyone is doing it - just wanted to double check :)

Also this is the only test that failed when I updated to v4! mikefarah/yq#2468

[ingydotnet]

https://play.yaml.io/main/parser?input=ZjoKICBhOiAmYSBjYXQKICAqYTogYiAgIyB0aGlzIHNwZWNpZmljYWxseQ==

That's invalid YAML because anchors can contain : chars.

libyaml and friends only allowed minimal [-a-zA-Z0-9] chars in anchors, but we expanded that.

the spec allows most printable unicode in anchors.

we changed go-yaml to allow the ascii allowed chars.

If this is causing pain, I have no problem in remeving : from the allowed chars in go-yaml.

Let me know.

[ingydotnet]

Honestly, I think we should remove : for now.

Maybe even remove it from the spec in a future YAML spec 😄

[ccoVeille]

Maybe even remove it from the spec in a future YAML spec 😄

Hey, that's cheating!!! You we changing the rule. 🤣😂

Honestly, I think we should remove : for now.

More seriously, I agree with you

[ccoVeille]

What is the PR involved in this change?

I failed to find it back. I feel like it could be #47

[ingydotnet]

What is the PR involved in this change?

I failed to find it back. I feel like it could be #47

Yes. https://github.com/yaml/go-yaml/pull/47/files#diff-116f5076d34c636aefab7d3aa208d8fd1eb6beb514c2174720b605a4be572e9dR69

[ingydotnet]

I feel wrong about allowing invalid yaml (though we have for a long time here).

Maybe we could warn on this?

It would involve a change in the scanner which is hairy.

I guess I could revert the : for now and leave an open issue here to warn / deprecate / something else.

[perlpunk]

What I can say about this is that libyaml was at least changed a while back to emit a space after an alias, see yaml/libyaml#185 from 2020
For me it would depend on whether there are still libraries that do not emit the space.

[ingydotnet]

What I can say about this is that libyaml was at least changed a while back to emit a space after an alias, see yaml/libyaml#185 from 2020 For me it would depend on whether there are still libraries that do not emit the space.

I think that go-yaml should definitely emit a space after an alias key (as part of this triage).

The first order of business is to address the regression, imho.
Then we can work on the problems.

[ingydotnet]

Using https://github.com/yaml/go-yaml-cli we can see the current issue and how when we add the space it emits it without a space...

$ ./go-yaml -Y <<<'
foo: &a bar
*a: baz'
2025/09/10 11:23:20 Failed to process YAML:failed to decode YAML: yaml: line 3: could not find expected ':'
$ ./go-yaml -Y <<<'
foo: &a bar
*a : baz'
foo: &a bar
*a: baz

[ccoVeille]

Note

EDIT: Apparently I was writing things while @ingydotnet wrote his messages. So please consider the text under this note was written before reading Ingy's ones

I took some time to understand the issue.

Please bare with me, as I'm not an expert in YAML.

Here is my understanding:

• YAML spec supports having a : in an anchor
• This is then invalid

f:
  a: &a cat
  *a: b

While this is valid

f:
  a: &a cat
  *a : b

The reason is because an anchor/alias could be named a:, and the equivalent YAML would be this

f:
  a: &a: cat
  *a: : b

• the : could be anyware

So this would be possible

f:
  a: &a:b cat
  *a:b : b

Or this

f:
  a: &:a cat
  *:a : b

So for me if there is a problem with the YAML spec. It's the fact, an anchor/alias name can contain a : as a trailing character.

Because right now, with current YAML spec. It's not possible to write this:

f:
  a: &a:b cat
  *a:b: b

because a:b could be one anchor/alias, and a:b: another anchor/alias.

So with current YAML spec, I feel like there is a need for go-yaml to add a space after a alias used as a key in a map. Maybe it's already the case, I'm just reporting and sharing my thoughts.

Please tell me if my understanding is valid.

So, if we consider @mikefarah unit test. There is a need to fix it by using this

f:
  a: &a cat
  *a : b

Now, about the way go-yaml should parse this

f:
  a: &a cat
  *a: b

For me, it's invalid and cannot be accepted. So go-yaml should fail to read it.

Here I went into detail as I expect we had multiple unit tests for this.

[ccoVeille]

What I can say about this is that libyaml was at least changed a while back to emit a space after an alias, see yaml/libyaml#185 from 2020 For me it would depend on whether there are still libraries that do not emit the space.

I think that go-yaml should definitely emit a space after an alias key (as part of this triage).

The first order of business is to address the regression, imho.
Then we can work on the problems.

I feel like:

• go-yaml must respects the YAML spec.
• the spec allows : to be used in anchor/alias
• as a consequence, go-yaml must emits a space after an alias key.
• it must remain like for ever, at least for the current spec.

If the spec evolves, go-yaml could supports it via a set option specific to the new YAML spec, and then for example if : is totally forbidden in anchor name, or at least forbidden as the last character of an anchor name, it could then emit the alias key without a space.

So here, I would say the only things that is addressable and to be discussed is the fact if go-yaml should accept (via an option) to decode what is currently invalid according to spec, something like this (that is invalid) :

t:
  *a: 42

As if it was written like this

t:
  *a : 42

So the idea is to only focus on mitigating issue if the yaml/v3 was accepting this as being valid.

t:
  *a: 42

[ccoVeille]

This is a followup my previous comment.

#47 introduced a breaking change in the v4 compared to the v3

The issue comes from the YAML spec itself that can lead to ambiguous situation.

An anchor/alias can contain a colon character (:), but mapping have the colon delimiter to separate the key and value.

So this

m:
  a: &foo: 42
  b: &foo: 3.14
  *foo: b

Could be considered like this:

• the anchor foo is defined with 42
• the anchor foo: is defined with 3.14
• the foo alias is used in as a key in the m mapping

So it could be rendered like this

    m:
       a: 42
       b: 3.14
       42: b

This was the way go-yaml v3 was parsing it.

#47 changed this, by fixing other issues.

Now, because the spec is permissive/ambiguous

The same YAML

m:
  a: &foo: 42
  b: &foo: 3.14
  *foo: b

could be considered like this

• the anchor foo is defined with 42

• the anchor foo: is defined with 3.14

• the foo: alias is used in m mapping as if the YAML was

  m:
     a: 42
     b: 3.14
     3.14 b

Which would be invalid as a YAML.

Aliases are used in YAML mapping

https://github.com/search?q=language%3Ayaml+%2F%5C*%5Cw%2B%3A+%2F&type=code

I feel like the v4 should:

• emit a space after an alias used (no matter whether there is a trailing :
• refuse alias directly followed by a : in a mapping (and here expect a space)
• accept alias and anchor with a trailing : everywhere else

But the second item implies the v4 has a breaking change compared to v3.

One way to solve everything could be to refuse alias and anchor with a trailing :, but it's valid as part of the spec.

So maybe the solution could be in the middle, such as ignoring the trailing : when used as a key in a mapping. Most users are not aware of the issue with this notation, and most YAML libraries consider it as valid.

Here I feel like we could go it any direction.

We could also consider v4 should have sane default setting, and the refusing an alias directly followed by a colon. But the v3 was OK with this notation.

About this, maybe we should consider a mode that is not enabled by default in the v4 that will refuse ambiguous alias used as a key., or maybe refuse them anywhere as a key or an anchor. And another setting to not add a space between the alias and the : in a map. This way people can use what they want.

But here, people are lazy. They would either read the documentation and disable the rules. Or think the v4 is broken.

BTW, the current error messages reported by the current code is a bit cryptic. could not find expected ':'

From my perspective, here we are dealing with the edge cases of the YAML spec.

We could also move fast and consider v4 doesn't consider : as a valid character for anchor. It would be the same as the v3. And do nothing but emitting a space after a alias, so here without a setting.

Another move is to accept the : but not as a trailing character in anchors/aliases.

This might be better, maybe.

Whatever the direction we are going I'm fine with it. I just want it to be clear and documented.

[mikefarah]

I think this is fairly niche issue, and impact wise it won't be significant whichever way it goes. My 2 cents is that if we are in the opinion that it doesn't matter which we way go, then may as well stay backwards compatible with the v3 spec.

(I also think it's odd to allow ":" in anchor names, seeing as its strictly a yaml feature, and doesn't affect the actual data when it's de-normalised, I think the spec can afford to be more strict for simplification and not allow ":" 🤷🏼 )

Keen to get this resolved one way or the other!