There seems to be a logical problem (again) with templates. It's not really D's faulth. Imagine you have an array, right:

# class Array!(T) {
# public: // my bad
#   T[] data;
#   Array!(typeof(this)) split() { } // nope

What happens here is that if the compiler want to make the intermediate output,
it will recursively create types for split. For instance, for Array!(int) split
would return Array!(Array!(int)), and that on it's turn again return
Array!(Array!(Array!(int))) on split.

Though! I think it's 'sort of important' to implement some sort of a 'don't do it unless I ask for it' feature in the compiler, so that it would allow recursive class template definitions. For instance, if I had pop on the array (which they by standard do not), I could never make it work like this:

somearray.split(".").top()

because top would be a function of an array returned by split which is a template of array which you cannot do because... recursivenes. (hope you're still following ;))

The problem is, you never know when it's going to happen, and I think it's a hard to fix issue. I haven't actually tried this in C++ but I suppose it would work. C++ arrays sort of suck for not having split types and other thigns that return arrays from arrays though ;).

For now, I'm not that concerned about it, I can fix it again hackish by converting a base array type to a normal array type with another cast, as in the likes of:

Array!(char[]) Initial = "something.exe";
Array!(Array!(char[])) Foo = Initial.split(".");
Foo.top() -> "exe"

Instead of

Initial.split(".").top(); // imposible ;_; LAMENT!

Joey Peters wrote:
> There seems to be a logical problem (again) with templates. It's not really D's
> faulth. Imagine you have an array, right:
> 
> # class Array!(T) {
> # public: // my bad
> #   T[] data;
> #   Array!(typeof(this)) split() { } // nope
> 
> What happens here is that if the compiler want to make the intermediate output,
> it will recursively create types for split. For instance, for Array!(int) split
> would return Array!(Array!(int)), and that on it's turn again return
> Array!(Array!(Array!(int))) on split.
> 
> Though! I think it's 'sort of important' to implement some sort of a 'don't do
> it unless I ask for it' feature in the compiler, so that it would allow
> recursive class template definitions. For instance, if I had pop on the array
> (which they by standard do not), I could never make it work like this:
> 

From a compiler perspective, this would be an error.  Not even a C++
compiler would be able to do something like this AS WRITTEN.  C++ gets
around this issue by separating out things like "split()" into an
external function.  That makes it something that is only parsed and
processed _as_needed_.  If you rewrote it so that you have your
Array!(T) class and a separate split() function it would behave like
you expect:

// or whatever the right syntax is...
Array!(Array!(T)) split(Array!(T)) {}

That way when you perform split it looks like this:

Array!(int) intArray = new Array!(int)();

Array!(Array!(int)) splitArray = split(intArray);


That is why C++ doesn't include a split function on the array itself (I
bet).

> From a compiler perspective, this would be an error.  Not even a C++
>compiler would be able to do something like this AS WRITTEN.  C++ gets around this issue by separating out things like "split()" into an external function.  That makes it something that is only parsed and processed _as_needed_.  If you rewrote it so that you have your Array!(T) class and a separate split() function it would behave like you expect:
>
>// or whatever the right syntax is...
>Array!(Array!(T)) split(Array!(T)) {}
>
>That way when you perform split it looks like this:
>
>Array!(int) intArray = new Array!(int)();
>
>Array!(Array!(int)) splitArray = split(intArray);
>
>
>That is why C++ doesn't include a split function on the array itself (I
>bet).

Well yes, but I'd figure it could be a feature, simply by not forward referencing templates (terms get sort of woozy when you're being very specific), but only 'advance' if it's used. I can find a work around though.