On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm@gmail.com> wrote:
> Bill Baxter wrote:
>>
>> On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>> Sergey Gromov wrote:
>>>>
>>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>>> Andrei Alexandrescu wrote:
>>>>>
>>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to
>>>>> ask...
>>>>> any ideas? :o)
>>>>>
>>>>> One goal is to fix opIndexAssign and make it work similar to the way it
>>>>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
>>>>> test
>>>>> bed.
>>>>
>>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>>
>>> One problem is that for a hashtable that does not have b yet, opIndex
>>> will
>>> throw an exception.
>>
>> I don't see why you expect   a[b] += c to work on a key for which a[b] is undefined.  If it's undefined how can you increment it?
>
> Actually I did use it once to count things, so I could just use a[b]++ instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.

But D hashmaps don't work like that.
I guess std::map in C++ does behave like that, so that could explain
why Andrei would expect that behavior from a map data structure.

--bb

Andrei Alexandrescu wrote:
> KennyTM~ wrote:
>> Sergey Gromov wrote:
>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>> Andrei Alexandrescu wrote:
>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)
>>>>
>>>> One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.
>>>
>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>
>> Probably performance.
>>
>> Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1.
>>
>> But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c).
>>
>> (The same idea can be extended to properties and .opSlice() )
> 
> Glad you brought opIndexAddAssign up. I think a good solution would avoid adding all opIndexXxxAssign functions. I think even opXxxAssign are undesirable.
> 
> Andrei

Of course I don't want opIndexAddAssign either ;p.

Bill Baxter wrote:
> On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm@gmail.com> wrote:
>> Bill Baxter wrote:
>>> On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> Sergey Gromov wrote:
>>>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>>>> Andrei Alexandrescu wrote:
>>>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to
>>>>>> ask...
>>>>>> any ideas? :o)
>>>>>>
>>>>>> One goal is to fix opIndexAssign and make it work similar to the way it
>>>>>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
>>>>>> test
>>>>>> bed.
>>>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>>> One problem is that for a hashtable that does not have b yet, opIndex
>>>> will
>>>> throw an exception.
>>> I don't see why you expect   a[b] += c to work on a key for which a[b]
>>> is undefined.  If it's undefined how can you increment it?
>> Actually I did use it once to count things, so I could just use a[b]++
>> instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
> 
> But D hashmaps don't work like that.
> I guess std::map in C++ does behave like that, so that could explain
> why Andrei would expect that behavior from a map data structure.

No, it's not std::map. Actually, much to everyone's confusion, Walter hacked a[b]++ and ++a[b] to automatically insert typeof(a[b]).init at slot b in a if it didn't exist. Try it!

Andrei

On Sat, Oct 4, 2008 at 12:07 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Sat, Oct 4, 2008 at 11:57 AM, KennyTM~ <kennytm@gmail.com> wrote:
>>>
>>> Bill Baxter wrote:
>>>>
>>>> On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>>>
>>>>> Sergey Gromov wrote:
>>>>>>
>>>>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>>>>> Andrei Alexandrescu wrote:
>>>>>>>
>>>>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to
>>>>>>> ask...
>>>>>>> any ideas? :o)
>>>>>>>
>>>>>>> One goal is to fix opIndexAssign and make it work similar to the way
>>>>>>> it
>>>>>>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
>>>>>>> test
>>>>>>> bed.
>>>>>>
>>>>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>>>>
>>>>> One problem is that for a hashtable that does not have b yet, opIndex
>>>>> will
>>>>> throw an exception.
>>>>
>>>> I don't see why you expect   a[b] += c to work on a key for which a[b] is undefined.  If it's undefined how can you increment it?
>>>
>>> Actually I did use it once to count things, so I could just use a[b]++ instead of the clumsy if(b in a){a[b]++;}else{a[b]=1;}.
>>
>> But D hashmaps don't work like that.
>> I guess std::map in C++ does behave like that, so that could explain
>> why Andrei would expect that behavior from a map data structure.
>
> No, it's not std::map. Actually, much to everyone's confusion, Walter hacked a[b]++ and ++a[b] to automatically insert typeof(a[b]).init at slot b in a if it didn't exist. Try it!
>
> Andrei

Wierd. But yet plain a[b] will still throw an exception?

--bb

KennyTM~ wrote:
> Andrei Alexandrescu wrote:
>> KennyTM~ wrote:
>>> Sergey Gromov wrote:
>>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>>> Andrei Alexandrescu wrote:
>>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)
>>>>>
>>>>> One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.
>>>>
>>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>>
>>> Probably performance.
>>>
>>> Consider seeking to the end of a 100M-node single-linked list, and increase its content by 1.
>>>
>>> But I agree that if something like .opIndexAddAssign() is not defined, the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c).
>>>
>>> (The same idea can be extended to properties and .opSlice() )
>>
>> Glad you brought opIndexAddAssign up. I think a good solution would avoid adding all opIndexXxxAssign functions. I think even opXxxAssign are undesirable.
>>
>> Andrei
> 
> Of course I don't want opIndexAddAssign either ;p.

That would be hell on generic programming, too. These would only be useful for collections, which are usually templated for the element type. Then your collection class would look like:

static if (SupportsAddition!(T))
{
	void opIndexAddAssign(T value) { ... }
}

And then I define a class:
class BigInt
{
	void opAddAssign (long i) { ... }
}

And it all goes to hell.

That means you have to do:
mixin (AdditionSupport!(T)());

string AdditionSupport(T)()
{
	foreach (method; __traits(getVirtualMethods, T, "opAddAssign"))
	{
		// codegen here
	}
}


And that only works because of a bug in __traits(getVirtualMethods) that returns final methods.

opIndex*Assign is just an unreasonable solution for generic programming.

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>> Yes, we would need an alternate mechanism for properties - an addition to the language. And it's quite true that it's likely there would be disagreement in the "lot of people" about that. But there is only one way to be sure, so we could at least try! Would you and Walter at least consider this, and see if we could find an alternative that satisfies a fair number of people? Try without compromise.
> 
> What I'd consider is not that important. I do know what Walter's viewpoint is, and that is that there are plenty of bigger rocks to move.
> 

By "taking into consideration" I don't mean that he would implemented it right away. It's clear there are a lot of work being done in other important features. (Still, some of the property proposals, like the one below, could be quite simple if not trivial to implement)

>> In fact, I'm also not a fan of those complex property mechanisms, à lá C#. I think a fair candidate would be Bill Baxter's proposal, the 'property' keyword:
>>
>>   property int foo() { return _foo; };
>>   property void foo(int foo) { _foo = foo; };
>>
>> The property keyword would make a function callable *only* as a property syntax (either as reading, 'bar = foo;', or as writing, 'foo = 42;'). A function signature which was not adequate for property access would be compile-time error.
>> This proposal fixes the ambiguities issues, and require *minimal changes* to the language, both in terms of syntax and semantics!
> 
> Then what would obj.fun mean when fun is not a property?
> 
> Andrei
> 

Good question. One option would be for obj.fun to be a compile error, as mentioned.
But other yet, and cleaner IMO is for obj.fun to be the delegate value, ie, the same as the current "&obj.fun". The proposal's &obj.fun could be the same as obj.fun, as a deprecated syntax for backward compatibility.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Hold it right there! Are you saying that the existence of 'lazy' somehow required, or helped justify the existence of the omittable parenthesis functionality? How is that?
>> I think you are accusing innocents ('lazy') or wrongdoing. 'lazy' has nothing to do with the omittable parenthesis functionality, I think they are completely orthogonal. Prove me wrong otherwise.
> 
> The connection is indirect. Lazy showed that omitting trailing parens after delegate names is not recommended. If trailing parens after delegate names were required, much of the ambiguity mentioned by Sergey would disappear.
> 
> Andrei

So your point before was, that you are criticizing lazy because it shows/recommends that trailing parenthesis are not ommited?
Then you realize that such is only considered a disadvantage to those that think trailing parenthesis should be omitted in the first place...

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D