Andrei Alexandrescu, el 19 de noviembre a las 18:25 me escribiste: > Leandro Lucarella wrote: > >Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste: > >>Leandro Lucarella wrote: > >>>dsimcha, el 19 de noviembre a las 23:21 me escribiste: > >>>>Face it, D is a close to the metal language. Any attempt to define the > >>>>spec at a > >>>>purely abstract level without reference to any implementation details, > >>>>and without > >>>>leaving certain details implementation defined is absurd. I think people > >>>>need to > >>>>face the fact that you can't have close-to-the-metal flexibility and > >>>>performance > >>>>and at the same time far-from-the-metal strict separation of > >>>>specification from > >>>>implementation details. > >>>Yes, but I think this is a place where you are doing early optimization at > >>>the expense of usability. You can always do the slice-thinguie yourself if > >>>you are that needed for speed that you can't afford an extra indirection > >>>when using an array (which will be the only overhead if T[new] were > >>>implemented as a pure reference type). > >>> > >>>I think the cost here in terms of usability if far higher than the little > >>>performance you loose, specially when you can overcome the issue for those > >>>weird cases where you need it. > >>I think one aspect that tends to be forgotten is that built-in > >>arrays are the lowest abstraction - really just one small step above > >>pointers. Efficiency lost there is lost forever. That's why I > >>consider the current design adequate and the proposed designs less > >>so. > > > >I don't think so, slices (a view over somebody elses memory, no appending) > >should be the lowest level abstraction. > > > >>In other words: you can build a more convenient facility on top of > >>T[], but you couldn't build a more efficient facility on top of a > >>convenient one. I think D made the right choice with built-in > >>arrays. > > > >I don't. Current built-in arrays are both dynamic arrays and slices, which > >is what messes all up. > > Well it also makes arrays/slices quite capable.
Yes, capable of introducing bugs specially =) > Right now they only have one problem (which different people ascribe > a different gravity to) and are otherwise very expressive. Nobody is judging the expressiveness of arrays, the bug-prone semantics is the problem. > Now think of this: the MRU solves a grave issue with slices. You are using arrays and slices interchangeably on purpose, right? I hate you! =) > We haven't thought of that for years, and all of a sudden stomping is > not an issue anymore. And suddenly you are tying array implementation with the GC. You are making things worse, not better. This whole issue reminds me to this blog: http://thereifixedit.com/ =P > I wouldn't be in the least surprised if someone posts in this group > tomorrow that they found a way to make ~= more predictable. Split slices and arrays, add a capacity field to arrays, remove appending from slices. There. > >But I'll drop the subject, once again, for the sake of... well, everybody > >;) > > I encourage you to further your point (while in understanding that > your existing arguments and proposals have been understood). This is > the best time to make a contribution to D's design. I keep replying just because I can't control myself, but I really think it's pointless, I have said (as many others) several times what are the problems and what would be a nice solution. You just find the solution unsuitable and think the cache is good enough. > We may as well undefine "~" or "~=" or both for arrays if there's > enough arguments and evidence that it's a problem to keep them. I think that would be very bad. For once, I thought "~" where out of discussion, because it always create a new temporal (like any other binary operator), so I can't see a problem with it. And I hope you are only seeing as a possibility to remove "~=" from slices, making possible for a library array type to define it. I can totally lived with that. If the array type were imported in object.d it would be even better. > When making proposals just keep in mind one important thing: with the > context that you (all) have accumulated regarding this discussion, a lot > of things seem very easy to understand, which are really weird when just > starting with the language. Please, name them! And BTW, understanding the MRU cache (and trying to predict it) will be any easier? > One other thing is that it's all tradeoffs; things that are "good" > in all dimensions are in very short supply. I know that! This discussion is just because some think one tradeoff is better than the other. > With arrays, we may be in the position of choosing a solution that won't > please everyone. The question right now is "which 5% of users you will > disappoint". I really think more than 5% of the users will hit the weird half value half reference semantics of slices, but, of course, I'm making this figures up, just like you did ;) > As for reviving T[new], I believe that, unless some new insight comes > forward, practically that ship has sailed. That doesn't preclude > defining a library type that is a more encapsulated array. I don't care about T[new], I'm fine with a library defined type. Just remove appending from slices (and make .length read-only). > Fortunately, that can be implemented using T[] because T[] is expressive > enough :o). ... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Relax. I'll need some information first. Just the basic facts. Can you show me where it hurts?