Less Code Bloat from Templates

[Jonathan Marler via Digitalmars-d]

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...