Leandro Lucarella Wrote: > Steven Schveighoffer, el 24 de diciembre a las 10:15 me escribiste: > > 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.
In fact, semantics are simpler. You can completely eliminate the explanation about stomping in the spec. > > > 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? No example? > 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. Really? You think splitting the features into 2 different types with several overlapping features is easier to explain? I think that is why Andrei nixed the T[new] idea, because when he tried to explain it in TDPL, it was very unnatural. > 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. I think the whole basis of your argument is invalid -- the current array/slice combination type is easier to use and explain *and* performs better. -Steve
