[swift-evolution] Overloading assignment operator

[Don Wills]

Hello Ilya, 

> On Dec 6, 2015, at 3:05 PM, ilya <ilya.nikokoshev at gmail.com> wrote:
> 
> Yes, I meant for the email to go to the list. 
> 
> > Nope, that doesn't work because of my comment above.  That's the change to Swift I am hoping will be adopted for 3.0.
> 
> Did you try this? The idea is to write a function for multiplying a Number and an Int, so the rhs will create a Number which will then be set to the variable. It should work actually. 

Yes, I've written a class named Number with many "func <operator> ( ... ) { ... }" implementations for the various permutations of Number, Double and operators.  They all work except for when <operator> is the equal sign.

Don

> On Mon, Dec 7, 2015 at 00:47 Don Wills <don.wills at portablesoftware.com <mailto:don.wills at portablesoftware.com>> wrote:
> Hello Ilya,
> 
> On Dec 6, 2015, at 1:09 PM, ilya <ilya.nikokoshev at gmail.com <mailto:ilya.nikokoshev at gmail.com>> wrote:
>> 
>> On Sun, Dec 6, 2015 at 5:26 PM, 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.
>> 
>> 
>> This is not really the same. You only use + explicitely, but the compiler must insert some assigments automatically, for example by copying when the function closes over some variables. It must know exactly what the semantics in this case is to be able to compile correct program.
> 
> My example wasn't the best.  IMO, there is almost no conceptual difference between "amount = 5.5;" and "amount += 5.5;".  The second example works (that is += can be overloaded) where the first example is not allowed because when I try to define the "func = (...) {...}" overload implementation, the compiler squawks.
> 
> 
>> 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.  
>> 
>> I'm with you.
>>  
>> 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 didn't look into the new Foundation, but doesn't it contain NSDecimalNumber? 
>>  
>> 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)
>> 
>> 
>> I'm not sure why you feel the need to overload = in this example. If Number * Int -> Number is defined, you can just use
>> 
>> result = amount * 4
> 
> Nope, that doesn't work because of my comment above.  That's the change to Swift I am hoping will be adopted for 3.0.
> 
> Did you mean to not post your email to me only?  I haven't figured out the protocol for this email list yet.
> 
> Don Wills
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/55d7ddd7/attachment-0001.html>