While I will agree that enforcing types on simple inputs/outputs can be overkill for a project, how grounded is that narrative to the real world with large-scale projects? Personally speaking, your example in the type inference section speaks to 1% of any codebase I've worked on this decade. I'd dare argue that the majority of functions written & maintained today involve objects for inputs & outputs
I agree that most functions are going to work on complex types like objects or records, but they can be inferred just as well as strings or numbers.
That example was only intended to show that you need to add types to functions where the parameters have already been typed, the types themselves don't really matter.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I will agree that enforcing types on simple inputs/outputs can be overkill for a project, how grounded is that narrative to the real world with large-scale projects? Personally speaking, your example in the type inference section speaks to 1% of any codebase I've worked on this decade. I'd dare argue that the majority of functions written & maintained today involve objects for inputs & outputs
I'm not sure what you mean here, sorry.
I agree that most functions are going to work on complex types like objects or records, but they can be inferred just as well as strings or numbers.
That example was only intended to show that you need to add types to functions where the parameters have already been typed, the types themselves don't really matter.