Editing PermissiveImportsProposal (section)

==Possible issues==

The current behaviour encourages a sort of measure-twice-cut-once mentality. If we've explicitly imported a function by mistake and are expecting the implicitly imported version to be used we would normally get an ambiguous occurrence, whereas when using this we would either get a type error or no error if the mistakenly imported function is type correct. I'm not sure if this would be an issue in practice, as it requires you to be importing a function with the same name, same type, and different semantics, which I don't think is common. Likewise, it relies on having mistakes in your import list, which can already cause bugs even with the current behaviour.

However, it is still more permissive than currently. Import statements would also be slighly less local: if I see "import Data.List" at the beginning of the import list and I miss the "import Data.Text (isInfixOf)" at the other end of the list I could mistakenly think uses of isInfixOf in the module use the list version, when they are really using the Text version. These issues might be more common in large projects with a large number of imports and contributors. At least with a pragma it's opt-in, and easy to change if a project later decides the redundancy is useful.