template ideas, not a proposal (yet), open for criticism

[dylanrafael05]

Motivation

Allowing for easy-to-read, easy-to-create, and performant methods which use operators, indexers, or properties of an unknown type.

Core features

A template is either a class (see Templates on classes) or a function which has one or more "template parameters".
For example, here is a function with a template argument;

public T Min<template T>(T a, T b) where T: IComparable
{
   return a.CompareTo(b) <= 0 ? a : b;
}

When calling Min, the template argument must be provided, and it must be of constant form. This means that a template argument must either be:

• A type name
• Another template argument
• A constant of the argument's specified type, if it has one (see below section on typed args)

A call to Min, for example Min<int>(0, 1) will be treated as a call to some function Min__int, which the compiler generates during compilation, with the signature int Min__int(int a, int b). The compiler will decide which types must be used to generate a new function based on usage in the given code (possible due to the constant restraint on arguments).

This function Min__int will be equivalent to a function where all instances of T are replaced with int. This means that, similar to a normal generic, constraining the type of T using a where statement permits access to specific functions and operations that only a subset of types have.

"defines" constraint

Although templates are not particularly useful in the above case, template arguments also have access to a new type of constraint, defines. The syntax for this is as follows:

where T: defines /*some field definition, property definition, operator definition, indexer definition, constructor definition, or function definition, without access modifiers or any functionality */

The defines constraint checks if the template type T contains the given field, property, function, indexer, constructor, or operator, and that this item is accessible in the current scope. Similar to where T: ISomeInterface, anything stated to be defined by some template argument T can be used within the code where T is defined. For example;

public T Min<template T>(T a, T b) where T: defines static T operator <=(T a, T b) 
{
    return a <= b ? a : b;
}

Important things to note:

• The parameter names a and b are completely useless to the compiler, and serve only to allow for better code suggestion, as it would be otherwise impossible to tell the names of these parameters
• For any named definition (eg; int length), the name is checked.

Properties, indexers, and constructors have special rules when used with defines.
For properties:

//Invalid syntax, the following is treated as an auto-implemented property, which therefore has functionality
where T: defines int Length { get; }

//Valid; matches only properties with a get accessor, no accessible set.
where T: defines int Length { get }
//Valid; matches any properties with a get accessor, set accessor may or may not exist or be accessible in scope.
where T: defines int Length { get set? }
//Valid; matches any properties with a set accessor, no accessible get. (Mostly useless, but here for thoroughness)
where T: defines int Length { set }
//Valid; matches any properties with a set accessor, get accessor may or may not exist or be accessible in scope.
where T: defines int Length { get? set }
//Valid; matches any properties with both an accessible get and set
where T: defines int Length { get set }
//Invalid; does not provide any well-defined behavior to be used in the template
where T: defines int Length { get? set? }

//note: get must come first if it exists

Indexer accessors follow the same rules as property accessors
For indexers: (subject to change)

//valid, but the use of "this" could be confusing
where T: defines int this[int idx] { get set? }
//this makes more sense
where T: defines int T[int idx] { get set? }

For constructors: (subject to change)

//use the template name to denote construction
where T: defines T(int a, int b)

Typed template arguments

Template args may also be given a type, denoted with a type placed between template and the parameter name, provided the type can be represented as a constant value;

//definition
public int Bitmask<template byte bit>() 
{
    return 1 << bit;
}

//calling
public int bitmask5 = Bitmask<5>();

Note: the above function is especially useful because the compiler would recognize bit as a constant value, and likely replace all functions with return (value of 1 << bit);, or even better inline the function as a literal. This is because the compiler sees any call to Bitmask as it would any other non-generic function call, having broken the function up into many based on the values of bit provided.

These "typed template arguments" may not be constrained using where

Argument order

There can be an arbitrary number of template arguments for anything which uses them.
All template arguments must go before normal generic arguments, and template constraints cannot reference normal generics:

//valid
public int CompareToClone<template T, K>(T a, K b) where K : IComparable 
{
    return b.CompareTo(a);
}

//invalid, because K may be inferred, leaving CompareToClone<int> ambigious 
//between CompareToClone<int, missing> and CompareToClone<inferred, int>
public int CompareToClone<K, template T>(T a, K b) where K : IComparable 
{/*...*/}

//invalid, there is no way for the compiler to deduce what T can and cannot be
public int CompareToClone<template T, K>(T a, K b) where T: K where K: IComparable 
{/*...*/}

Templates on classes

Templates may also be applied to classes, where the same rules about pre-compilation and template argument order and specifics apply;

public unsafe class FixedIntList<template int size>
{
    public int[size] buffer;
}

Further features

A possible extension of these templates would be the introduction of deducible template types, for example;

//the ? following template in R's definition denotes that it is deduced in the following where constraints
//all template? arguments must be deduced, and therefore cannot be provided by the user
//if the where constraint does not exist, or does not use/disambiguate R, throw a syntax error
//if R remains ambiguous for some type T, throw an error for all calls to the function using T
public R First<template T, template? R>(T vals) where T: defines R this[int idx]
{
   //given T = string[], R could only be string
   //given T = object[], R could only be object
   //given T where T: defines char this[int idx], for example string, R is char.
   return vals[0];
}

Typed template arguments cannot be deduced.

End

Any thoughts? :P

[huoyaoyuan]

This can't be support by current CLR, and requires very heavy modification.

[dylanrafael05]

I don't see why it couldn't be, it would be run entirely from a precompiler (with the exception of reflection, which im deciding to remove anyway), no artifacts of templates even existing would be found in the outputted code. The outputted code would be similar to a set of overloads for the templated object, or a set of differently-named objects.

Furthermore, I fail to see problems with non-CLR compliance. Much of C#'s System namespace contains non-complaint code.

[huoyaoyuan]

it would be run entirely from a precompiler (with the exception of reflection, which im deciding to remove anyway)

That's the way F# works.

Even without reflection, there is still metadata representation to solve to make it work cross assembly.

[alrz]

This is very similar to shapes proposal, except that member signatures are not inlined. See #164

[dylanrafael05]

Shapes appear to use a type-check on an object itself. Shapes also do not account for typed arguments. My suggestion is a pre-compiled (similar to a macro) solution with no tradeoff for speed.

Furthermore, new posts help to bring attention to the subject. Writing math libraries is extremely annoying. Any solution is a good solution in my eyes.

[HaloFour]

Shapes are a part of a larger conversation around generic concept/constraints in general. The primary goal is to enable the scenarios that cover generic math and to do so as a zero-cost abstraction.

Part of this whole project that is currently under active design in the runtime and language is the ability to define abstract/virtual static members on interfaces and classes. That will presumably be used to drive new generic constraints against those virtual static members and the runtime will be able to specialize implementations based on the actual generic type argument. The shapes part of that equation in the language will enable bridging existing types to those constraint interfaces without them having to implement the interfaces directly.

In short, the language and runtime teams are very aware that generic math is a pain point and they are actively working towards features that will make them easier while not compromising on performance.