Daniel Keep wrote:
> 
> Tim M wrote:
>> Firstly option 2 was just crazy and I don't know why you said that.
> 
> Because it's how .NET does it.  Granted, .NET doesn't really have
> templates; just deferred type erasure.  Still, it's basically the same idea.

This is a much easier feature to support, assuming you have sufficient reflection. You'd output some type constraints for the metadata on the generic element. On instantiation of a generic method, the runtime would check the given type against those constraints. Local variables of the generic type would be stored in an array on the heap, perhaps, or you could extend the stack as necessary. Methods and properties would all be accessed via reflection.

Dog slow, and it only works out as syntactic sugar. It isn't worthwhile.

Tim M wrote:
> On Mon, 09 Mar 2009 00:58:14 +1300, Michel Fortin <michel.fortin@michelf.com> wrote:
> 
>>
>> If you introduce a way to limit templates to what generics can do in Java and C#, you can have virtual template functions. Java and C# generics can do only do a subset of what templates can do, but this ensure there's only one compiled code instanciation. So perhaps non-final non-static member template functions could be constrained to generic-like operations and thus could become virtual.
>>
>> I remembrer myself proposing this a few months ago, but it didn't caught on.
>>
> 
> 
> 
> I remember you blogging about a way of compiling base classes with new methods and not needing to recompile the sub classes, I will read up on those genrics in C# and java later. If that doesn't work out, what if the compiler could check for all sub class functions within the same module and allowing a sort of limited virtual template functions, so no work through external libraries. I would prefer limited virtual over no virtual.

People would constantly complain and file bug reports about the limitations. It's all or nothing. Nothing is the superior choice here.

Jason House Wrote:

> Denis Koroskin Wrote:
> 
> > On Sun, 08 Mar 2009 06:44:48 +0300, Jason House <jason.james.house@gmail.com> wrote:
> > 
> > > The ugly const thread got me thinking about the old problem of returning
> > > an
> > > input while preserving const safety.  I have an idea that seems
> > > reasonable...
> > >
> > > In a nutshell, I'm thinking that const(T) should be a base type for T,
> > > immutable(T) and return(T).  return(T) is treated in a read-only fashion,
> > > just like const(T) and immutable(T). Here are some of the key things I
> > > think
> > > this achieves:
> > >   * Input arguments are never mutated
> > >   * Use of input parameters in calls to functions as const(T) is 100%
> > > legal.
> > >   * Temporary variables can legally be defined and used
> > >   * Calling other functions that return return(T) is allowed
> > >   * No code duplication
> > >   * No code bloat (compiler only needs to generate one version of the
> > > code)
> > >   * Functions can be virtual
> > >
> > > Let's take a relatively simple example: max
> > >
> > > return(T) max(return(T) a, return(T) b){ return (a>b)?a:b; }
> > >
> > > When max is called, the compiler would examine the inputs for a and b to
> > > determine what the true type for return(T) is from the callee's
> > > perspective...  So a call with T and immutable(T) would use const(T) as
> > > the
> > > perceived return type while an argument of T and T would use T as the
> > > return
> > > type.
> > >
> > > At the call site, the compiler would ensure type safety of how the return
> > > type is used.  Within max, the compiler would ensure that the arguments
> > > are
> > > either treated as const(T) in function calls but not mixed with with
> > > types
> > > T, const(T), or immutable(T)
> > >
> > > PS: The return(T) notation is an arbitrary one for the purposes of this
> > > post.  We need a technical solution before worrying about the color of
> > > the
> > > bicycle shed
> > >
> > 
> > How about this one?
> > 
> > class Foo {
> >     T value() {
> >         return _value;
> >     }
> >     T value() const {
> >         return _value;
> >     }
> > }
> 
> My proposal did not handle that. I wasn't thinking of that case.
> 
> 
> > You suggest turning it into:
> > 
> > return(T) value() {
> >     return _value;
> > }
> > 
> > Which is fine but it doesn't say anything about constness of 'this'.
> > 
> > In fact, you propose *exactly* the same thing I've been proposing multiply times in past under a different name, though:
> > 
> > sameconst(T) max(sameconst(T) a, sameconst(T) b) {
> >     return (a > b) ? a : b;
> > }
> > 
> > class Foo {
> >     sameconst(T) value() sameconst(this) { // return value has the same constness as 'this' (mutable, const or immutable)
> >         return _value;
> >     }
> > }
> > 
> > The constness is automatically propogated based on parameters. For example,
> > - sameconst(T) == T if all the parameters are mutable
> > - sameconst(T) == immutable(T) if all the parameters are immutable
> > - sameconst(T) == const(T) otherwise
> 
> 
> I'll take another look at your proposal. I thought of sameconst as a type alias rather than a typedef. I was mostly thinking of how this problem could be handled by the type system.

Maybe my web searches are failing me, but all I found was your posts in the "equivalent functions" thread. The details there were sparse. In that thread, your first post did not support sameconst(this), but was added a bit later. As far as I can tell, it died with Andrei posting he felf his solution was more general. I hated Andrei's reuse of typeof.

Daniel Keep wrote:
> In other words,
> 
> return(T) max(return(T) a, return(T) b){ return (a>b)?a:b; }
> 
> Would be similar to the following:
> 
> T max(T a, T b){ return (a>b)?a:b; }
> const(T) max(const(T) a, const(T) b){ return (a>b)?a:b; }
> invariant(T) max(invariant(T) a, invariant(T) b){ return (a>b)?a:b; }
> 
> Except that each would share a single implementation.

Sounds like you want to declare a template along with a list of types for which it should be instantiated. If the list is defined along with the template, there’s no reason the set of functions couldn’t be made virtual.

—Joel Salomon

On Sat, 07 Mar 2009 22:44:48 -0500, Jason House wrote:

> The ugly const thread got me thinking about the old problem of returning an input while preserving const safety.  I have an idea that seems reasonable...

I agree, it's very reasonable.  That's why I created an enhancement bugzilla for it last March (almost a year ago) :)

http://d.puremagic.com/issues/show_bug.cgi?id=1961

I agree the bikeshed color should not be a sticking point, but I do not think your proposal of re-using return will work.

Specifically, return(n) in a function body has a meaning already, it would be ambiguous to the parser probably.

I don't really love the inout(T) notation that Janice came up with, but it has an advantage that no new keywords need to be created.  I'm ok with another new keyword or some punctuation/existing keyword combo (e.g. const?(T))

But I'm glad we both came up with the same solution, it further gives more validation to the idea.  Please vote up my bugzilla report and add comments if you want.

-Steve

On 2009-03-08 08:16:42 -0400, "Tim M" <a@b.com> said:

> I remember you blogging about a way of compiling base classes with new  methods and not needing to recompile the sub classes, I will read up on  those genrics in C# and java later. If that doesn't work out, what if the  compiler could check for all sub class functions within the same module  and allowing a sort of limited virtual template functions, so no work  through external libraries. I would prefer limited virtual over no virtual.

Well, if you add a way to dynamically insert methods into objects, as I was indeed proposing on my blog, the only missing step is to compile the template at first use and insert it into the virtual table. But that would require a compiler in the runtime and preservation of the template source and its related types (perhaps as bytecode).

What I was proposing in the post you quoted doesn't require anything special in the runtime or the language other than the ability to impose restrictions about what a template can do in a virtual function to make sure that, whatever the template arguments, it always emit the same code. That'd work for return values using the same constness as an argument; it'd also work for making return values being of the same class as an argument when your function expect a base class.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Jason House Wrote:

> Maybe my web searches are failing me, but all I found was your posts in the "equivalent functions" thread. The details there were sparse. In that thread, your first post did not support sameconst(this), but was added a bit later. As far as I can tell, it died with Andrei posting he felf his solution was more general. I hated Andrei's reuse of typeof.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=76920

Kagamin Wrote:

> Jason House Wrote:
> 
> > Maybe my web searches are failing me, but all I found was your posts in the "equivalent functions" thread. The details there were sparse. In that thread, your first post did not support sameconst(this), but was added a bit later. As far as I can tell, it died with Andrei posting he felf his solution was more general. I hated Andrei's reuse of typeof.
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=76920

Hmmm... I guess I consistently like the same syntax. The value of my recent proposal was more about how the type system would work under the hood. Still, it appears others beat me to the same conclusion.