On Mon, 03 Nov 2014 16:39:43 +0000 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 3 November 2014 at 00:16:48 UTC, ketmar via > Digitalmars-d wrote: > > error-prone code. no, this is not "another task for lint". not > > rejecting such code is "safe" in the terms of "program will not > > segfault", but it's obviously not safe in terms of "correct > > code". > > Yes, this is a common complaint. Without solid semantic analysis > it would probably be better to only have dynamic vectors as a > library type with fat slices that are locked to the underlying > array. That's what everybody expects from a dynamic array type > anyway. …it is a reaaallyyy good idea to support what most > people's assumptions about dynamic arrays… > > D would gain more from relaxing "memory safe" language constructs > and focus more on supporting programming constructs by semantic > analysis. This is an area where the C++ crowd will be gridlocked > to their backwards compatible mindset. But they are getting > increasingly more powerful sanitizers… good semantic analysis as a big task, i think we all understand it. as moving dynamic arrays out of core language is the thing that surely won't be approved, the only sane way to safely fix this issue without starting discussion about when .ptr must be loaded is just reject impure assigns to dynamic array elements. sure this will reject some cases where impure assigns are ok, but better be safe that sorry, isn't it? ah, it isn't for D. sure, this decision will break some code. that's why it will never be approved, despite all hype about "safety". at least leaving this feature "as is" should help C++ programmers to adopt D. they used to languages that has nothing common with sanity. ;-)
signature.asc
Description: PGP signature