Should we add `a * b` for vectors?

Steven Schveighoffer schveiguy at yahoo.com
Fri Oct 6 12:51:07 UTC 2017


On 10/5/17 3:40 PM, Walter Bright wrote:
> On 10/5/2017 6:13 AM, Steven Schveighoffer wrote:
>> On 10/3/17 10:00 PM, Walter Bright wrote:
>>> On 10/3/2017 5:24 PM, Steven Schveighoffer wrote:
>>>> It also can be cheaper to pass a small struct by value.
>>>
>>> Should not be a problem if the compiler inlines it.
>>
>> That's not always possible.
> 
> Right. But then the question becomes how much more complexity do we want 
> to add chasing that last percent of perfection?

It all depends on how much you value convenience of operators. I can 
already do something like:

a.add(b);

which would "fix" the issue.

> 
> For example, right now I'm in my 3rd day of attempting to resolve
> 
>    https://issues.dlang.org/show_bug.cgi?id=17635
> 
> which is a regression brought about by layers and layers of fixes over 
> time for a seemingly simple issue - implicitly converting a unique 
> return from a pure function into an immutable.
> 
> For another example, it took Martin and I months to implement the new 
> import lookup scheme. It turned out to be fairly complicated, and there 
> were many regressions. There are probably still issues lurking in it.

The import changes modified how existing code worked. This is not the 
same thing. Of course you need to take more care of features that are 
going to break a lot of projects and make sure they don't. I spent a 
long time fixing the cycle detection, but had to figure out a way to do 
it such that it allowed people to use the old broken detection if they 
wanted to. That was not an easy thing to do, and took about 4 iterations.

> We need to keep the language rules simple enough to understand and 
> simple enough to implement, and there will be compromises with that.

I understand, and agree. I was just noting one reason why allowing 
operator overloading outside the type itself could be useful. It doesn't 
even have to be full-blown UFCS, it could be as simple as aliasing a 
member to an external function, which doesn't require any new changes to 
lookup rules.

In addition, inlining doesn't get around certain requirements for 
calling (e.g. the nice property of being able to implicitly cast away 
const).

-Steve


More information about the Digitalmars-d mailing list