Re: [RFC] std.experimental.concepts
On Friday, 24 July 2015 at 23:13:25 UTC, deadalnix wrote: On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote: I put up a PR for phobos awhile ago for concepts as a library to kind of start the discussion around concepts. There seemed to be some interest around the PR, so I have rebased it and fixed the formatting. Please take a look: https://github.com/D-Programming-Language/phobos/pull/2627 -Shammah Doing it as a library would miss a lot of the point of concepts : - Compiler can do a fair amount of semantic analysis on template before instantiating them. This work is done once rather than repeating it a every template instantiation. - It allow for much more clearer error messages. Anyone having to maintain some meta code will understand what I'm talking about here. - It make compile time and runtime polymorphism more alike. I do think we'd all agree that Andrei approach to mention template arguments as compile time arguments and go from there is a good move. Concept would be the same move, but for typing. By reusing common language constructs (C++ failed to use that opportunity) for instance. Agreed, that's why I left the PR alone for so long before someone pinged me on it. I sort of did it as a POC and didn't quite end up liking the results. The library solution would be okay if it was easier to get diagnostics -- but currently that requires nasty hacks if you looked at the docs.
Re: [RFC] std.experimental.concepts
On Sunday, 26 July 2015 at 15:24:45 UTC, Andrei Alexandrescu wrote: I think we disagree here. It doesn't seem to me that adding features to D is helpful at this point. -- Andrei I'm all for not adding new stuff.
Re: [RFC] std.experimental.concepts
On Sunday, 26 July 2015 at 15:24:45 UTC, Andrei Alexandrescu wrote: On 7/25/15 7:25 PM, deadalnix wrote: On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't. I think we disagree here. It doesn't seem to me that adding features to D is helpful at this point. -- Andrei I think thats valid, D is already too big. I for one would actually be more happy if some things were removed, rather than added. Template specialization and template constraints for one could probable be folded into the same thing. Structs vs Classes is weird. The default GC. Properties also being kinda weird. Lots of little warts. Always hoping for a D3. It has become my HL3 for programming languages, it wont ever happen, but I still hope. And if it did, it would be the most glorious thing ever.
Re: [RFC] std.experimental.concepts
On 07/25/2015 04:14 PM, Martin Nowak wrote:
On Saturday, 25 July 2015 at 14:06:05 UTC, Daniel N wrote:
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote:
I put up a PR for phobos awhile ago for concepts as a library to kind
of start the discussion around concepts. There seemed to be some
interest around the PR, so I have rebased it and fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is a fun
trick?
It almost works, if only IFTI was smart enough to deal with eponymous
identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Templates are not bijective, so we'll never be generally able to
determine T by matching Putty, i.e. 2 different T could have the same
Putty!T type.
Adding an exception for identity templates seems to be a hack.
It does not need to be just for identity templates. It can work for all
templates not involving non-trivial introspection on the template arguments.
Re: [RFC] std.experimental.concepts
On 7/25/15 7:25 PM, deadalnix wrote: On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't. I think we disagree here. It doesn't seem to me that adding features to D is helpful at this point. -- Andrei
Re: [RFC] std.experimental.concepts
On 7/25/15 10:18 PM, Tofu Ninja wrote: On Saturday, 25 July 2015 at 23:25:27 UTC, deadalnix wrote: On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't. Also having both basically destroys walter's augment about it getting tedious adding constraints at the top level. Having both would mean its opt-in. I kind of agree with that. Yet it doesn't make a strong case for adding traits to D. I think we shouldn't. -- Andrei
Re: [RFC] std.experimental.concepts
On 7/24/15 7:13 PM, deadalnix wrote: On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote: I put up a PR for phobos awhile ago for concepts as a library to kind of start the discussion around concepts. There seemed to be some interest around the PR, so I have rebased it and fixed the formatting. Please take a look: https://github.com/D-Programming-Language/phobos/pull/2627 -Shammah Doing it as a library would miss a lot of the point of concepts : - Compiler can do a fair amount of semantic analysis on template before instantiating them. This work is done once rather than repeating it a every template instantiation. Interesting. - It allow for much more clearer error messages. Anyone having to maintain some meta code will understand what I'm talking about here. Agreed, though I would more if much were dropped. - It make compile time and runtime polymorphism more alike. I do think we'd all agree that Andrei approach to mention template arguments as compile time arguments and go from there is a good move. Concept would be the same move, but for typing. By reusing common language constructs (C++ failed to use that opportunity) for instance. Meh to that. Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 14:06:05 UTC, Daniel N wrote:
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor
wrote:
I put up a PR for phobos awhile ago for concepts as a library
to kind of start the discussion around concepts. There
seemed to be some interest around the PR, so I have rebased it
and fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is
a fun trick?
It almost works, if only IFTI was smart enough to deal with
eponymous identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Templates are not bijective, so we'll never be generally able to
determine T by matching Putty, i.e. 2 different T could have the
same Putty!T type.
Adding an exception for identity templates seems to be a hack.
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 14:14:52 UTC, Martin Nowak wrote: Templates are not bijective, so we'll never be generally able to determine T by matching Putty, i.e. 2 different T could have the same Putty!T type. Adding an exception for identity templates seems to be a hack. If it only was done for the sake of IFTI, then yes indeed it would be a hack, but probably other things as well such as shorter mangling could benefit from the compiler being aware of identity templates.
Re: [RFC] std.experimental.concepts
On 26/07/2015 2:14 a.m., Martin Nowak wrote:
On Saturday, 25 July 2015 at 14:06:05 UTC, Daniel N wrote:
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote:
I put up a PR for phobos awhile ago for concepts as a library to kind
of start the discussion around concepts. There seemed to be some
interest around the PR, so I have rebased it and fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is a fun
trick?
It almost works, if only IFTI was smart enough to deal with eponymous
identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Templates are not bijective, so we'll never be generally able to
determine T by matching Putty, i.e. 2 different T could have the same
Putty!T type.
Adding an exception for identity templates seems to be a hack.
==
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(!T)(Putty!T t)
{
}
===
void fun(__original_T)(__original_T t) if (is(Putty!__original_T ==
__original_T))
{
}
===
Humm, minor rewrite of source by the front end. Definitely would be doable.
Re: [RFC] std.experimental.concepts
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote:
I put up a PR for phobos awhile ago for concepts as a library
to kind of start the discussion around concepts. There seemed
to be some interest around the PR, so I have rebased it and
fixed the formatting.
Please take a look:
https://github.com/D-Programming-Language/phobos/pull/2627
-Shammah
For those who are on a sugar-rush from Concepts, maybe this is a
fun trick?
It almost works, if only IFTI was smart enough to deal with
eponymous identity templates.
int fun(T)(T t) if(is(typeof(T.Put)))
{
}
template Putty(T)
{
static assert(is(typeof(T.Put)));
alias Putty = T;
}
void fun(T)(Putty!T t)
{
}
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy.
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't.
Re: [RFC] std.experimental.concepts
On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei
Re: [RFC] std.experimental.concepts
On Saturday, 25 July 2015 at 23:25:27 UTC, deadalnix wrote: On Saturday, 25 July 2015 at 22:09:08 UTC, Andrei Alexandrescu wrote: On 7/25/15 5:24 PM, deadalnix wrote: On Saturday, 25 July 2015 at 13:41:22 UTC, Andrei Alexandrescu wrote: Now stack these advantages against the advantages of template constraints. It's a landslide. Andrei This is a false dichotomy. We could have both (i.e. add traits to D), but would we want to? -- Andrei Yes. Most template code would benefit from it. For the same reason that being able to bypass the type system is important, you also would like that most of the code don't. Also having both basically destroys walter's augment about it getting tedious adding constraints at the top level. Having both would mean its opt-in.
Re: [RFC] std.experimental.concepts
On Sunday, 26 July 2015 at 02:18:34 UTC, Tofu Ninja wrote: Also having both basically destroys walter's augment about it getting tedious adding constraints at the top level. Having both would mean its opt-in. Just noticed I wrote augment instead of argument...
[RFC] std.experimental.concepts
I put up a PR for phobos awhile ago for concepts as a library to kind of start the discussion around concepts. There seemed to be some interest around the PR, so I have rebased it and fixed the formatting. Please take a look: https://github.com/D-Programming-Language/phobos/pull/2627 -Shammah
Re: [RFC] std.experimental.concepts
On Friday, 24 July 2015 at 19:56:55 UTC, Shammah Chancellor wrote: I put up a PR for phobos awhile ago for concepts as a library to kind of start the discussion around concepts. There seemed to be some interest around the PR, so I have rebased it and fixed the formatting. Please take a look: https://github.com/D-Programming-Language/phobos/pull/2627 -Shammah Doing it as a library would miss a lot of the point of concepts : - Compiler can do a fair amount of semantic analysis on template before instantiating them. This work is done once rather than repeating it a every template instantiation. - It allow for much more clearer error messages. Anyone having to maintain some meta code will understand what I'm talking about here. - It make compile time and runtime polymorphism more alike. I do think we'd all agree that Andrei approach to mention template arguments as compile time arguments and go from there is a good move. Concept would be the same move, but for typing. By reusing common language constructs (C++ failed to use that opportunity) for instance.
