> By all means, please reconsider this, and leave me the choice to define the
> operators. If I want "+" for concatting, it is trivial to define it myself.
> I don't need the language to force that and eseentially destroy operator
> overloading for mathematical operations on dynamic arrays.
Same h
> On Jun 2, 2018, at 1:44 PM, Michael Van Canneyt
> wrote:
>
> 2 remarks:
> 1. It's only for arrays
> 2. It's for fixed-length arrays
>
> So you can do this in FPC today.
>
> Thirdly, you have objects which can be allocated on the stack, or advanced
> records.
>
> Plenty of choice for you.
> On Jun 2, 2018, at 2:17 PM, denisgolovan wrote:
>
> Same here.
>
> The semantics for vector operations on arrays was thoroughly explored in
> vector languages (APL, A+, J, K, etc).
> Doing per-element dyadic function application is the basis for it. Having
> proper operators overloads is c
denisgolovan schrieb am Sa., 2. Juni 2018, 09:18:
> @Sven
> Please reconsider "+" operator for arrays if your changes really forbid to
> overload operators for arrays now.
>
It wasn't me who implemented that part. I personally had planned to do it
with a warning for existing overloads, but Flori
> On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal
> wrote:
>
> It wasn't me who implemented that part. I personally had planned to do it
> with a warning for existing overloads, but Florian beat me to it and
> implemented it this way. Though when asked by me he did say that we'll wait
On Sat, 2 Jun 2018, Ryan Joseph wrote:
On Jun 2, 2018, at 1:44 PM, Michael Van Canneyt wrote:
2 remarks:
1. It's only for arrays
2. It's for fixed-length arrays
So you can do this in FPC today.
Thirdly, you have objects which can be allocated on the stack, or advanced
records.
Plenty o
> On Jun 2, 2018, at 2:54 PM, Michael Van Canneyt
> wrote:
>
> Personally, I don't understand the obsession with language features.
> If anything, I would make the language more simple. But this is just me
> swimming against the current.
Ironically I totally agree but it’s so difficult to de
It's technically possible.
But for vector operations to be valid/consistent both of them should work the
same way. That is perform arithmetic per-element addition.
BTW, you first overload is not implemented properly. You need to clone "left"
first and return it as a result.
BR,
Denis
___
Yes, I strongly support removing that functionality in favor of user operator
overloads or vector-compatible way.
Moreover, SSE/AVX vector extensions also should work per-element.
I mean those vectors as in https://bugs.freepascal.org/view.php?id=27870
BR,
Denis
_
On 02/06/18 08:00, Ryan Joseph wrote:
On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal
wrote:> > It wasn't me who implemented that part. I personally had planned to do it with
a warning for existing overloads, but Florian beat me to it and implemented it this way.
Though when asked by me
On 06/02/2018 02:01 AM, Ryan Joseph wrote:
So it looks like my idea wasn’t that crazy after all. ;)
just because more than one person comes up with the same or similar idea does
not mean that it is not crazy or worse ;) ;) ;)
--
NOTE: No off-list assistance is given without prior approval
> Sven Barth via fpc-pascal hat am 2. Juni
> 2018 um 09:42 geschrieben:
>
> denisgolovan < denisgolo...@yandex.ru> schrieb am Sa., 2. Juni 2018, 09:18:
> > @Sven
> > Please reconsider "+" operator for arrays if your changes really forbid to
> > overload operators for arrays now.
>
>
> I
denisgolovan schrieb am Sa., 2. Juni 2018, 10:28:
> Yes, I strongly support removing that functionality in favor of user
> operator overloads or vector-compatible way.
>
To clear something up: this new operator will definitely not be removed.
Period.
What might be done however (and what I had p
Mark Morgan Lloyd schrieb am Sa., 2.
Juni 2018, 10:53:
> However as Dennis points out + is also essential for vector operations.
> Perhaps either leaving it to the programmer to define what's needed
> would be the best approach, or alternatively splitting dynamic arrays
> into mathematical vector
Did anyone have any idea about this or should I just file a bug report for now?
I don’t want to forget about it if possible.
> On Jun 2, 2018, at 1:05 PM, Ryan Joseph wrote:
>
> type
> generic TMyCollection = record
>class operator := (values: array of T): TMyCollection;
> e
> On Jun 2, 2018, at 3:19 PM, denisgolovan wrote:
>
> BTW, you first overload is not implemented properly. You need to clone "left"
> first and return it as a result.
That’s probably the functionality you want but as an aside why can’t + overload
mutate the caller (left side) and not return
16 matches
Mail list logo
