[swift-evolution] floating point numbers implicit conversion

[Xiaodi Wu]

On Sat, Jun 17, 2017 at 3:21 PM, Ted F.A. van Gaalen <tedvgiosdev at gmail.com>
wrote:

> Hi Xiaodi
>
> in 1966-1970 PL/I, a static-typed procedural block-structured programming
> language
> far ahead of its time,  with the purpose of giving "all things to all
> programmers”
> was introduced by IBM as their main (mainframe) programming flagship.
>
> I’ve worked with PL/I very often during my life. It is truly general
> purpose and has tons
> of features and is because of that quite overwhelming for starters like me
> in 1976 after
> Fortran as my first PL.  PL/I  is a bit like riding a gigantic powerful
> motor cycle without
> much instruction from the start and without training wheels back then of
> course.
> Took some time to master PL/I (no screens let alone IDEs back then),
> however, with
> the great reward to be in control of one of the most powerful PLs on the
> planet.
>
> You might ask, what’s  the context of this somewhat nostalgic emission:
> :o)
>
> PL/I also has many data types like Binary, Bit, Character Complex, Decimal
> Fixed, Float,Picture etc. of various lengths and storage
> .
> Implicit data type conversion (coercion) between almost all PL/I data
> types has
> been available in PL/I right from the start. No problem - that is if you
> know what you are doing.
> What exactly to expect from conversions in PL/I is always predictable, also
> because it is described in detail in the programming manuals.
> Furthermore PL/I diagnostics and warnings are excellent.
>
> So, implicit data type conversion (coercion) has been successfully
> implemented and used in an
> already complex programming language (in some cases far more advanced as
> Swift - apart from
> OOP) almost 40 years ago…
> It is now 2017 and you’re telling me that coercion is too difficult to
> implement in Swift ??
>
> On 16. Jun 2017, at 18:19, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Implicit promotion has been brought up on the list before, many times over
> many years. The scale and implications of the change not to be
> underestimated.
>
> It should be not so difficult I think… as it simply replaces
> explicit casts and the compiler can detect implicit conversions easily;
> be it in assignments, with expression operands or as call parameters.
>
> To give a taste of what would be involved, consider that new integer
> protocols were recently implemented that allow heterogeneous comparison;
> these have proved to be tricky to implement in a way that preserves user
> expectations in the context of integer literals. (I will write shortly with
> thoughts on revisiting certain specifics.)
>
> Yes, can’t react on this need more information, I don’t see this in
> context of “user expectations” either.
>
> btw, I was merely discussing Floating Point conversion <=>  Integers?
>
>
> Implicit promotion would be much more complicated.
>
> Why do you think so?
> float = double  // compiler inferred type conversion, what’s so difficult
> about this assignment?
> Currently  you’d have to use
> float = Float(double)  // and you’re doing (explicitly) exactly the same
> thing.
>
>
> There is little point in discussing whether such a feature in the abstract
> is desirable or not.
>
> Abstract? I don’t think so and have described this subject fairly
> concrete,
> illustrated with some examples.
> To me and certainly also many others this feature is desirable.
> As your say yourself
> “it has been brought forward so many times”
> Obviously many desire this feature and find this important.
>

Ted, you'll find no disagreement from me that this feature is desirable.
Now, having agreed on that, how do you intend to design and implement it?
How would you expand the type system to accommodate these rules? How would
you formalize the revised rules for type inference? What new protocols
would you add that allow non-builtin types to participate? What existing
code would break, and how would you migrate it? There's no way to proceed
with the conversation until someone proposes a design.

> It would be necessary to have a detailed proposed design and evaluate
> whether the specific design is desirable, in light of its interactions with
> other parts of the system.
>
> after gathering more insight, yes.
>
> For one, I think it’s important that no code that is currently legal
> produce a different result: this in itself is not trivial to achieve.
>
> As you know, Swift currently does not facilitate implicit conversion
> (coercion),
> which implies that current code (which of course does not contain implicit
> conversions)
> will function exactly as it does now,
>

That is not implied. Swift has type inference, which means that, with the
implementation of implicit promotion, the inferred type of certain
expressions that are legal today will change. For instance, integer
literals have no type of their own and are inferred to be of some type or
another based on context. When combined with bitwise operators, the
presence or absence of overloads that allow heterogeneous operations can
change the result of code that compiles both before and after the
implementation of the feature. This is just one example of why implicit
integer promotion in a strictly typed language with type inference and
without certain generics features is very hard.

when it was compiled in a Swift version in which
> implicit conversion were implemented.
>
> Kind Regards,
> TedvG
> www.tedvg.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170617/8560f9b9/attachment.html>