[Swift-devel] case sensitivity

[Mihael Hategan]

On Mon, 2011-09-19 at 11:44 -0500, Michael Wilde wrote:
> I feel that backwards compatibility - at least for some length period
> of time, but better yet indefinitely - needs to take priority over
> aesthetic issues.

I suppose we could have both toInt and toint, but it seems a bit shady
in the long run. Perhaps the best choice would be to do that for now and
generate a warning message when the undesired form is encountered.

> 
> So I can see providing and documenting a function like toInt() while
> indefinitely allowing toint(). I agree that we should be consistent is
> using camelCase.
> 
> However, until Yadu's email below I was never aware of any case
> insensitivity in Swift - I always programmed as if all names were case
> sensitive. I didnt pay close attention to the brief list discussion on
> case below. Was there any follow-up discussion?
> 
> Can you summarize what the issues are?

Swift shouldn't allow you to define f twice. We agreed that it can only
be a mistake to have a function defined twice (since there is no way to
access the first - lexically - definition).

So Yadu provided a patch to detect that. But then the question was what
would happen if both f and F were defined. From swift's case sensitive
perspective it would be ok. But in the case insensitive implementation F
would override f. So that had to be fixed.

> 
> I believe that Swift should be fully case sensitive for all names, and
> that we should not cause existing user code to break unless the cost
> of such backwards compatibility is much worse than the breakage.

I agree.