earthquake changes of std.regexp to come

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from dsimcha (dsimcha at yahoo.com)'s article
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>> I'm quite unhappy with the API of std.regexp. It's a chaotic design that
>>> provides a hodgepodge of functionality and tries to use as many synonyms
>>> of "to find" in the dictionary (e.g. search, match). I could swear
>>> Walter never really cared for using regexps, and that is felt throughout
>>> the design: it fills the bullet point but it's asinine to use.
>>> Besides std.regexp only works with (narrow) strings and we want it to
>>> work on streams of all widths and structures. One pet complaint I have
>>> is that std.regexp puts a class around it all as if everybody's favorite
>>> pastime would be to inherit Regexp and override some random function in it.
>>> In the upcoming releases of D 2.0 there will be rather dramatic breaking
>>> changes of phobos. I just wanted to ask whether y'all could stomach yet
>>> another rewritten API or you'd rather use std.regexp as it is for the
>>> time being.
>>> Andrei
>> As I've said before, anyone who can't stomach breaking changes w/o complaining has
>> no business using D2 at this point.  I'd rather deal with the aggravation of stuff
>> breaking in the sort run to have a nice language and libraries to go with it in
>> the long run.
>> This whole concept of ranges as you've created them seems to have achieved the the
>> holy grail of both making simple things simple and complex things possible, where
>> "complex things" includes needing code to be efficient, so I can see your reason
>> for wanting to redo all kinds of stuff in them.  This compares favorably to C++
>> STL iterators, which are very flexible and efficient but a huge PITA to use for
>> simple things because the syntax is so low-level and ugly, and to the D1/early D2
>> way, which gives beautiful, simple notation for the more common cases (basic
>> dynamic arrays), at the expense of flexiblity when doing more complicated things
>> like streams, chaining, strides, etc.
> 
> BTW, can you elaborate on how arrays, both builtin and any library versions, will
> work when everything is finalized?

Well finalizations hinges not only on me but on Walter (bugfixes and a 
couple of new features) and on all of you with the continuous stream of 
great suggestions and ideas. Again, without being able to experiment 
much I don't have a clear idea on how arrays/containers should at best 
look like. The interesting challenge is accommodating good, precise 
semantics with the freedom given by garbage collection. Here are some 
highlights:

* Today's T[] will be firmly an incarnation of the random-access range 
concept, to the extent that all code expecting a random-access range can 
always be passed a T[] without any impedance adaptation.

* $ will be generalized to mean "end of range" even for infinite ranges.

* We don't have a solution to address the perils of extending a slice by 
using ~=. We're considering adding the type T[new], but I'm not sure we 
should take the hit of a new built-in type constructor, particularly 
when it's implementable as a library.

* Fixed-size arrays will in all likelihood be value types. We couldn't 
find any other semantics that works.

* Containers will have value semantics.

* "Resources come and go; memory is forever" is the likely default in D 
resource management. This means that destroying e.g. an array of File 
objects will close the underlying files, but will not deallocate the 
memory allocated for them. In essence, destroying values means calling 
the destructor but not delete-ing them (unless of course they're on the 
stack). This approach has a number of disadvantages, but plenty of 
advantages that compensate them in most applications.

* std.matrix will define memory layouts for a variety of popular 
libraries and also the common means to iterate said layouts.

* For those who want containers with reference semantics, they can use 
the type Class!(T) for any value type T. That includes built-in value 
types (int, float...) and whichever value containers we define. It's 
unclear to me whether this is enough to satisfy those in need for 
complex container hierarchies.


Andrei