# Require parameter names when referencing to functions

**URL:** <https://forums.swift.org/t/require-parameter-names-when-referencing-to-functions/27048>\
**Category:** Pitches\
**Tags:** collection\
**Created:** [July 17, 2019, 2:35am UTC](https://forums.swift.org/t/require-parameter-names-when-referencing-to-functions/27048 "2019-07-17T02:35:40Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\
**Post date:** [July 17, 2019, 3:26am UTC](https://forums.swift.org/t/require-parameter-names-when-referencing-to-functions/27048/6 "2019-07-17T03:26:38Z")

</div>

We should make this change and we should not undo it later. This misfeature causes source compatibility breaks left and right, complicates type checking, and makes code counterproductively vague. It's a vector for users to accidentally use underscored initializers and unsafe APIs. And it runs counter to the direction of the language towards treating parameter labels as part of a function's name. Kill it with fire.

(Specifically, `name` without parentheses should only ever match _nullary_ (zero-parameter) functions/methods/initializers called `name`. If they have any parameters, you should need to specify the parameter labels.)

**Edit** : It's worth noting that we can deprecate this kind of matching in any release, but we can only make it an error in a release with a new language version. (For example, Swift 5.1 promises full source compatibility with 5.0, so in 5.1 we could have added this as a warning but not as an error.)

---

_[View the full topic](https://forums.swift.org/t/require-parameter-names-when-referencing-to-functions/27048)._