On Thursday, 30 October 2014 at 13:44:46 UTC, Marc Schütz wrote:
On Thursday, 30 October 2014 at 12:51:50 UTC, Jonathan Marler
wrote:
I'm not sure what the status is on this, I remember Walter
saying in a conference (DConf 2014 I think) that he had an
idea to remove duplicate template instantiations by comparing
their generated code but I had another idea I thought I'd
share.
I'm calling the idea "CombinationTypes". Sort of a
"compile-time" concept that allows code to use multiple types
that would produce the same binary code but retains type
information. The first combination type I would introduce is
the "any*" or "any[]" types. For example, you could write the
following function:
any* limitPtr(any[] array) {
return any.ptr + any.length;
}
This is basically type erasure. It works well reasonably well
as long as only references are allowed. But it seems you want
to allow value types, too.
Ya, like I said I haven't thought of too many types (value types)
that would be useful so I thought I'd throw the idea out there
and see if anyone came up with anything. I think the "anybyte"
type could be pretty useful.
The advantage of using a combination type like "any" over say
"void" is the compiler knows what you are trying to do and
won't require you to perform any awkward casting. The
following code should work fine:
char[] mychars;
string mystring;
auto mycharsLimit = mychars.limitPtr; // mycharsLimit is a
char*
auto mystringLimit = mystring.limitPtr; // mystringLimit is a
immutable(char)*
The generated code for this function will be identical no
matter what the element type is.
Unfortunately not, only if it's an array of byte-sized
elements. If you pass a `wchar[]`, the calculation needs to be
<pointer + 2*length> instead of <pointer + length>.
It gets more involved if you want to allow copying and
assigning, because the types can have non-default `this()`,
`this(this)`, `~this()`, `opAssign()`, and so on.
Oh woops you are right. I guess this function would have to be
implemented like this:
any* limitPtr(any[] array, size_t elementLength = any.sizeof) {
return any.ptr + (elementLength * any.length);
}
That actually might be kind of confusing, the '+' operator on an
unknown pointer defaulting to size 1 isn't really intuitive.
Hmmm...I would have to think on this more.
One more thought that just came to me is maybe it would be useful
to add an array/pointer type to the language that held it's
element size at runtime. You could implement that currently
using casts and such, but having it as a first class type in the
language would make it easy to use. I don't know how helpful it
would be though, maybe not enough benefit for the amount of work
it would take to support it. I might call it something like
"dynamic*/dynamic[]" which would be the same as a regular
pointer/array except they have an extra size_t field called
elementSize. Just a thought...
