Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

Unfortunately it looks like these changes will actually incur a breaking change to the types of the public API. In some classes where ControlValueAccessor was implemented the function signatures for registerOnChange and registerOnTouched were more extensively typed. These were also incorrectly typed as returning an empty interface instead of the expected void return type.

I've fixed the typings for the classes that implement ControlValueAccessor internally, so these are no longer a problem. Existing applications that implement ControlValueAccessor incorrectly should fail to compile with TypeScript providing information about how to fix the problem.

Perhaps adding a code mod would be appropriate to fix the problem automatically?

So does this mean without the angular teams coordinating between the angular + angular/material libraries this is stuck? Is there a PR on the material side to correct this? This is arguably more important than the AbstractControl generic issues since without the ControlValueAccessor having generics you have no template side compile time safety, making the AbstractControl generics unsafe.

EDIT: Also, on the topic of this change for Template side compile time safety, should we break out the default value accessor to be more type specific based on the input type? (type number is a generic of number, type text a generic of string, type checkbox a generic of Boolean) It looks like its selector can be targeted like that.

@ShawnOzark That is essentially correct, however this change would not simply impact Angular Material but all libraries that make use of the ControlValueAccessor.

Closing this PR in favor of more recent #38406 and #38906. Thank you.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}