Hi Tino
> On 30.03.2016, at 15:07, Tino Heth <[email protected]> wrote:
>
> Sometimes, it's definitely desirable to have implicit conversion… but
> sometimes, it's not, so I think the current behavior is good.
> I guess most of us have a zero tolerance policy for warnings, so those would
> be treated like the current errors.
>
e.g. this should never be a problem at run time:
aFloat = anInteger
neither is this:
aCGFloat = aDouble
A warning is just that: a warning. simply notify the programmer, just in case
he/she does not fully understand the implications..
Eg. in PL/1 these are not warnings but Information type messages.
> It is possible to define operators that take numerics with different types as
> a workaround, and imho it wouldn't hurt to have a module that implements
> those operations.
Imho, that would add to much noise to Swift
You could of course handle conversion errors with a try/catch.
There is also extensive info how implicit data type conversion could be handled
here:
http://odl.sysworks.biz/disk$vaxdocsep953/decw$book/d3ndaa10.p77.decw$book
(it is relatively new, from 1992, conversion rules of ca. 1970, but don’t let
that bother you)
I’ve worked with many other languages too, but most of my reference
material is from PL/1,the parent of all procedural programming languages.
However writing a proposal with
“Replace Swift by PL/1 and add OOP features”
goes perhaps a bit to far :o)
TedvG
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
