[swift-evolution] Overloading assignment operator
ilya
ilya.nikokoshev at gmail.com
Sun Dec 6 16:05:18 CST 2015
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.
On Mon, Dec 7, 2015 at 00:47 Don Wills <don.wills at portablesoftware.com>
wrote:
> Hello Ilya,
>
> On Dec 6, 2015, at 1:09 PM, ilya <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> 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/723002b6/attachment.html>
More information about the swift-evolution
mailing list