On Sat, Dec 24, 2011 at 1:45 PM, Timon Gehr <timon.g...@gmx.ch> wrote: > On 12/24/2011 08:41 PM, Mr. Anonymous wrote: >> >> On 24.12.2011 21:22, Andrew Wiley wrote: >>> >>> On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr<timon.g...@gmx.ch> wrote: >>>> >>>> On 12/24/2011 07:00 PM, Andrew Wiley wrote: >>>>> >>>>> >>>>> On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr<timon.g...@gmx.ch> wrote: >>>>>> >>>>>> >>>>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote: >>>>>> >>>>>>> >>>>>>> 2011/12/24 Mr. Anonymous<mailnew4s...@gmail.com>: >>>>>>> >>>>>>>> On 24.12.2011 19:01, Denis Shelomovskij wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 23.12.2011 22:51, bearophile пишет: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ++a[] works, but a[]++ doesn't. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Already known compiler bug. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Is it a joke? Array expression in D are for performance reasons to >>>>>>>>> generate x2-x100 faster code without any compiler optimisations. >>>>>>>>> Link >>>>>>>>> to >>>>>>>>> one of these epic comments (even x100 more epic because of '%' use >>>>>>>>> instead of 'x###'): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> But `a[]++` should store a copy of `a`, increment elements and >>>>>>>>> return >>>>>>>>> stored copy. It is hidden GC allocation. We already have a silent >>>>>>>>> allocation in closures, but here a _really large_ peace of data >>>>>>>>> can be >>>>>>>>> allocated. Yes, this allocation sometimes can be optimized out >>>>>>>>> but not >>>>>>>>> always. >>>>>>>>> >>>>>>>>> IMHO, D should not have `a[]++` operator. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Why should it store a copy? o_O >>>>>>>> I also don't see any allocations in the code on the URL above. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> int a_orig = a++; >>>>>>> int[] arr_orig = arr[]++; >>>>>>> >>>>>>> If ++ is going to be applied to an array, it needs to have the same >>>>>>> meaning as it does elsewhere. After this operation, arr_orig and arr >>>>>>> must refer to different arrays for that to be true. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Not necessarily. >>>>>> >>>>>> class D{ >>>>>> int payload; >>>>>> D opUnary(string op:"++")(){payload++; return this;} >>>>>> } >>>>>> >>>>>> void main() { >>>>>> D d = new D; >>>>>> assert(d.payload == 0); >>>>>> assert(d++.payload == 1); >>>>>> } >>>>> >>>>> >>>>> >>>>> That doesn't match integer semantics: >>>>> int a = 0; >>>>> assert(a++ == 0); >>>>> assert(a == 1); >>>> >>>> >>>> >>>> Yes, that was my point. >>>> >>> >>> Then I'm not understanding what you're trying to prove. >>> I'm saying that if we implement a postfix ++ operator for arrays, >>> keeping the language consistent would require it to make a copy if the >>> user stores a copy of the original array. I guess it could be argued >>> that since arrays have hybrid value/reference semantics, no copy >>> should be made and the original should change. >>> >>> Actually, looking at it from that angle, a[]++ is fundamentally >>> ambiguous because it could have value semantics or reference >>> semantics, so I would argue that we shouldn't have it for that reason. >>> '++a' and 'a += 1' do not have such ambiguities. >> >> >> Maybe you're right, but a[]++; alone, imo, should compile. > > > +1.
You could special case this, but I'd be happy with an error that told you to use one of the working alternatives.