[swift-evolution] Overloading assignment operator

[Alex Lew]

Don, have you considered making your Number type FloatLiteralConvertible?
This would allow you not just to *let number: Number = 4.9*, but also pass
in 4.9 to a function that expected a *Number*. It would not let you set
Number variables to be equal to other variables of type Float, it seems
your main use case here is literals anyway.

http://swiftdoc.org/v2.0/protocol/FloatLiteralConvertible/

On Sun, Dec 6, 2015 at 9:26 AM, Don Wills via swift-evolution <
swift-evolution at swift.org> wrote:

> Silvan,
>
> Yes, I understand the concern you raise.  I too have held that general
> opinion of overloading operators in other languages for many years.  That
> said, overloading arithmetic and other operators causes the same
> opportunity for abuse.  For example, overloading + for integers to do
> something different (like rounding instead of truncation) would make
> maintenance of existing programs into a giant guessing game.
>
> That said, once the cat is out of the bag to overload operators, I don't
> see how adding support for = makes things any worse.
>
> FYI, the reason for my suggestion is to add support for fixed decimal
> arithmetic just like that available in COBOL.  Yeh I can hear the groans
> now.  However, for business applications, fixed decimal arithmetic is a
> basic feature that has been tossed away in new languages by language
> designers who don't actually labor in the trenches.  I've built a simple
> class to do just that - here is some sample code that uses my Number class
> that gives an idea of what the code does:
>
> var amount = Number(left: 6, right: 2);
> var result = Number(left: 9, right: 2);
> amount <- 3.9;
> amount += 1;
> result <- amount * 4;
> print(result)
>
> Note that <- is the assignment operator.  I am sure all would agree that =
> is superior in this situation.  Such code would be far more readable and
> the Number values would act just like and interoperate with Float and Int
> in all regards *except* that currently the = operator is not available for
> assignment.
>
> Don Wills
>
> PS.  FWIW, the  IEEE 754-2008 d128 alternative that Chris Lattner
> mentioned to me is inferior to the kind of support for fixed decimal
> arithmetic that I believe would help make Swift superior to C# for business
> applications.
>
>
> On Dec 6, 2015, at 6:58 AM, Silvan Mosberger < kametrixom at icloud.com>
> wrote:
>
> Hi Don
>
> I think this is a terrible idea! Imagine what you’d be able to do with
> that:
>
> let x : String = 3
>
> This would lead to the same problems already discussed with implicit
> initialisers:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000531.html,
> just worse. Also assignment is something more fundamental than other
> operators, I doubt it’s even possible to do that.
>
> On 06 Dec 2015, at 14:44, Don Wills via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> The ability to overload operators is very useful.  However, that utility
> is diminished without the ability to overload the simple assignment
> operator ( = ).  I vaguely recall reading somewhere that there is a reason
> for this having to do with syntax ambiguity.  Can this problem be solved so
> that = can be overloaded?
>
> Don Wills
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> Untracked with Trackbuster <https://trackbuster.com/?sig>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/810dbab9/attachment.html>