Why 2.8? Shouldn't it be 2.7?

It's a fix for issue #24247. The reported version is 2.8 so i decided to do it for this version. Before v2.8 ArrayKeyChoiceList was used which is deprecated since v2.8. I could do a patch for 2.7 but i was not really sure.

@ro0NL any review here, since you commented on the linked issue?

it's a new feature no? still think we should not implicitly trim (user known) choice options =/

@ro0NL agreed, we should not trim model data.

What bugs me is : why are input keys trimmed in the first place? I understand why values are trimmed by default, but keys, it's wrong. Isn't that the root issue?

why are input keys trimmed in the first place?

Que? That's exactly what's not happening right?

The name "foo " contains illegal characters. Names should start with a letter, digit or underscore and only contain letters, digits, numbers, underscores ("_"), hyphens ("-") and colons (":").

(contains a space)

Am i missing a trim call?

DX-wise what could be done is resolve a default trim=true|false option for the choice type. If we know options contains spaces we should set trim=false i guess.

If we need to trim the model, it means the user input keys have been trimmed before. Why? That's what I mean.

Ah right.. isnt the selected choice HTML wise the submitted value? Thus trimmed depending on trim=true|false.

edit: i see that's in fact model data we implicitly trim..

So.. setting trim=false by default for choicetype would be sufficient actually?

@ro0NL looks like so!

@ro0NL or @hliebe up to do the PR? (setting trim=false on choicetype)

Changing the value of the trim option as a bug fix may introduce weird behavior in some existing applications (because values submitted before were mapped to choice models thanks to the trim, even if this is the responsibility of the client to send a trim value).

Ok to change the value of the trim option, but this change must be documented ⚠️.

@HeahDude would be great if you could submit a PR doing so.

See #26932.