Allow for block types with optional labels

[johakoch]

For couper we use an hcl-based configuration language. The language defines some block types that have optional labels, e.g.:

api {
}
api "my_api" {
}

are both valid. (In this configuration language there are no block types with more than one label.)

We implemented this in a fork by allowing a third token optional following label, e.g.

type API struct {
	// ...
	Name                 string    `hcl:"name,label,optional"`
	// ...
}

, which is not conformant with gohcl/doc.go:

// Within each tag there are two comma-separated tokens. The first is the
// name of the corresponding construct in configuration, while the second
// is a keyword giving the kind of construct expected.

. (We could also have used another "second" token, like optional_label, to get the same effect, though.)

Do you think this may be of use for other hcl-based languages as well?

[apparentlymart]

Hi @johakoch!

Looking in your fork, I see that you've implemented it only for the native syntax, in package hclsyntax.

For this to be merged upstream it would need to work in the JSON variant too, but that's not really possible because it makes the interpretation of the syntax ambiguous. That's why this isn't supported in HCL today.

If you only care about the native syntax and are willing to keep maintaining your fork then of course this is fine! But for this upstream HCL we expect language designers to use a different block type name for each block header signature, because that then gives the JSON syntax decoder a hook to understand which interpretation the author intended.

[johakoch]

Hi @apparentlymart
Yes, we only support the HCL native syntax.

So we will keep a fork and try to maintain it as time allows.

Thanks anyway

[johakoch]

Hi @apparentlymart
Could the optional label

api {
}

be a short form of an empty label

api "" {
}

, which could have a JSON representation of

{
  "api" {
    "": {
    }
  }
}

?

[apparentlymart]

Hi @johakoch,

That seems tricky if a block type has more than one label. I think it's clearer for each block type to have a fixed number of labels, rather than having a surprising shorthand for just one specific situation. It's also harder for the decoder to give good feedback about incorrect usage if there is more than one possible interpretation of a given input, so we've tried to avoid that as much as possible.

(Older versions of Terraform had quite awful error messages in large part because older versions of HCL were too forgiving in having many different ways to describe the same data structure. HCL 2 traded that flexibility for giving HCL more information to use when reporting errors.)

[johakoch]

Hi @apparentlymart

Yes, it would only be applicable for blocks that have at most one label. So I guess it's not possible in a generic way.