[swift-evolution] Overloading assignment operator

[Stephen Celis]

I think that his number assignment (via `<~`) depends on the current state of `amount`, and that using FloatLiteralConvertible does not provide enough information at the call site (since the current value is not available in the initializer).

Stephen

> On Dec 6, 2015, at 1:43 PM, Alex Lew via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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/ <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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto:swift-evolution at swift.org> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution> 
>> 
> 
> Untracked with Trackbuster <https://trackbuster.com/?sig>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> 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/889fcc3e/attachment.html>