Steven Schveighoffer, el 24 de diciembre a las 10:15 me escribiste: > Leandro Lucarella Wrote: > > > This is making the half-value, half-reference semantics of arrays even > > worse, since now the capacity is "passed by reference" (at the end of the > > array data) but the length and ptr as values. > > This is absolutely false. It does not make anything worse. It may not > make it as good as you want, but it definitely is better than the > current situation.
I meant from the language semantics POV (you have more rules to remember about arrays), I agree it makes things better from a practical POV. > > I don't comment much about the patch (and the design) because I already > > did so in the several threads about it. I think is a very bad idea, > > I think dynamic arrays should be a proper reference type (with ptr, length > > and capacity) and slices should be a value type without appending (only > > with ptr and length). > > I don't agree. I like that slices and arrays are the same type, it > allows for much cleaner code, and much less function duplication. I see > the "append extends into a block" as an optimization, one that currently > is invalid, and with the patch is valid. Disallowing appending to > slices means you must generate arrays whenever you want to do appending > (which copies the entire slice), incurring a higher cost for little > gain. I'd actually say no gain. Do you have an example where such > a scheme is better than arrays with my patch? > > Note that nobody is stopping you from making such array types, you are > free to add them. I said this several times but here it comes again: We agree that the current scheme is better in terms of performance than having a proper reference type dynamic array and a separated slice value type. The thing is, I think optimization is nice as long as it doesn't leak the abstractions to the user. The current scheme is clearly this scenario, to make an optimization (one that problably a lot of people wouldn't need), you are making things harder for the user and creating a monster half array, half slice that is harder to understand than 2 smaller and simpler types. You think this performance gain is more important than the added complexity, I think the other way. You think D should be *by default* as fast as possible, even when making the programmers life a little harder, and let the user create or use library types for easy use and I think it should be the exact opposite, make *default* things easier and not as fast, and let the user create/user library types if they need top performance/optimizations. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO... -- Crónica TV
