On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
> Ah, I guess it is very similar after all, except it'd be based on top of and coexist with all of D's design by introspection stuff (rather than exist without it as with C++), thus avoiding a lot of the downsides and getting best of both worlds.

You've seen this, right?

https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.

On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
> Ah, I guess it is very similar after all, except it'd be based on top of and coexist with all of D's design by introspection stuff (rather than exist without it as with C++), thus avoiding a lot of the downsides and getting best of both worlds.


You've seen this, right?

https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.

On Monday, 10 July 2017 at 16:16:40 UTC, bpr wrote:
> On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
>> Ah, I guess it is very similar after all, except it'd be based on top of and coexist with all of D's design by introspection stuff (rather than exist without it as with C++), thus avoiding a lot of the downsides and getting best of both worlds.
>
>
> You've seen this, right?
>
> https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint
>
> A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.

Sorry about the repeat posting, I could observe the software hiccuping on my browser...

On 07/10/2017 07:32 AM, Jacob Carlborg wrote:
> 
> Something like this has been proposed several times before, but Andrei doesn't seem to like it. He think it's a failure that all the conditions need to have a name, or something like that. I prefer your approach.
> 

Well, the nice thing about this approach (basing a concept-ish system *on top* of existing D-style design-by-introspection, as opposed to a C++-like concepts with no D-like features to complement it), is that it *doesn't* require every little variation to be named.

For example, in the same psuedo-code I posted, there's a function (the last join() overload) that takes an input range, but requires the input range to support hasLength. But notice that there is NO symbol created or used anywhere for InputRangeWithLength. IIUC, it sounds like C++ concepts would require such a symbol to be created. But with this, that would not be needed.

One thing to keep in mind is that we're ALREADY creating names for many (not all, but definitely some) of these things. In effect, *every* time we have an 'isXXXXX' function (isSomeString, isForwardRange, etc), we're already creating a name for it. We already implicitly understand that just because it's unrealisting to name *everything* (which, indicentally, reminds me of old Java class hierarchies), doesn't mean we can't or shouldn't name some things.

The other important thing I want to emplasize yet again (just in case, because I know from experience in the past it's exactly this kind of point that rarely gets noticed), I'm not proposing D do this. It'd be far too big a change and it's far too incomplete to even think of trying to push. (Even tiny straightforward improvements to D face dowwnright epic levels of resistance any more.) So again, it's just some brainstorming. Maybe D several decades from now, maybe some other language inspired by D, maybe nothing ever, whatever.

On 07/10/2017 11:58 AM, bpr wrote:
> 
> You've seen this, right?
> 
> https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint
> 
> A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.
> 

Yea, I've seen that. It'd be a nice improvent for D and I'm definitely in favor of it.

It doesn't especially excite me though just because it's a small incremental change and creates further syntactical differences between handling runtime-oriented symbols and compile-time-oriented symbols. Ie, I'd prefer "InputRange r" over "T r if InputRange" because it's vastly simpler and more consistent with non-templated variable declarations. But in a practical sense, that's be a much more major and difficult to retrofit that onto D, so the DIP sounds like an appropriate (if unexciting) direction for D to take.

But what I find much more interesting than that DIP (again, from a purely academic standpoint) is taking all of these abilities and finding a way simplify them, while retaining all of their power, and create more overall consistency[1]. (That was *exactly* one of my big original draws to D in the first place - it took C++, then cleaned it all up and enhanced it. I have interest in brainstorming the same for D. I think there's been enough practical experience using D at this point for more streamlined designs to now be possible.)

[1] Heck, on the consistency front, it even bugs the hell out of me when people do "foo()" to call/define a function, but then deliberately stick with "if ()"-style instead for keywords. Both are "identifier followed by parens", but whether or not a space is added between is *different* depending on whether the identifier is a symbol or a keyword. Unnecessary inconsistency. Maybe it's all the puzzle games I've played over my lifetime, but...want...to...simplify... ;)

On 07/10/2017 09:16 AM, Martin Nowak wrote:
> On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky (Abscissa) wrote:
>> SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}
> 
> Looks like concepts.
> 
> We've settled on leveraging the already useful template constraints (at best in CNF [¹]) for better error messages. It's on the Agenda for later this year [²].
> 
> [¹]: https://github.com/dlang/phobos/pull/5461
> [²]: https://wiki.dlang.org/Vision/2017H2_draft
> 

Sounds nice.

But I'm getting the distinct impression people are missing that I never actually proposed that D itself should do this. It's just academic brainstorming.

On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:

> Well, the nice thing about this approach (basing a concept-ish system
> *on top* of existing D-style design-by-introspection, as opposed to a
> C++-like concepts with no D-like features to complement it), is that it
> *doesn't* require every little variation to be named.
>
> For example, in the same psuedo-code I posted, there's a function (the
> last join() overload) that takes an input range, but requires the input
> range to support hasLength. But notice that there is NO symbol created
> or used anywhere for InputRangeWithLength. IIUC, it sounds like C++
> concepts would require such a symbol to be created. But with this, that
> would not be needed.
>
> One thing to keep in mind is that we're ALREADY creating names for many
> (not all, but definitely some) of these things. In effect, *every* time
> we have an 'isXXXXX' function (isSomeString, isForwardRange, etc), we're
> already creating a name for it. We already implicitly understand that
> just because it's unrealisting to name *everything* (which,
> indicentally, reminds me of old Java class hierarchies), doesn't mean we
> can't or shouldn't name some things.

I agree, it's not me that need convincing :)

> The other important thing I want to emplasize yet again (just in case,
> because I know from experience in the past it's exactly this kind of
> point that rarely gets noticed), I'm not proposing D do this. It'd be
> far too big a change and it's far too incomplete to even think of trying
> to push. (Even tiny straightforward improvements to D face dowwnright
> epic levels of resistance any more.) So again, it's just some
> brainstorming. Maybe D several decades from now, maybe some other
> language inspired by D, maybe nothing ever, whatever.

Here I disagree. I think that D should have something like this.

-- 
/Jacob Carlborg

On 07/10/2017 02:55 PM, Jacob Carlborg wrote:
> On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:
>> The other important thing I want to emplasize yet again (just in case,
>> because I know from experience in the past it's exactly this kind of
>> point that rarely gets noticed), I'm not proposing D do this. It'd be
>> far too big a change and it's far too incomplete to even think of trying
>> to push. (Even tiny straightforward improvements to D face dowwnright
>> epic levels of resistance any more.) So again, it's just some
>> brainstorming. Maybe D several decades from now, maybe some other
>> language inspired by D, maybe nothing ever, whatever.
> 
> Here I disagree. I think that D should have something like this.
> 

Oh, I didn't mean to imply that I wouldn't love to have it in D (assuming it was all well-fleshed out and didn't have big problems). I just wanted to be crystal clear that I'm merely discussing a langauge design idea here rather than coming in saying "Hey, you people should all like this idea and go implement it put it into D!!!" It's easy for things to get taken that way here, and can result in knee-jerk reactions and otherwise derailing of what's really only intended as a theoretical academic discussion. If something *were* to come of it, and it worked great, and everybody was happy, then fantastic. That's just not what I'm bringing it up for, that's all.

On 07/10/2017 04:14 PM, Nick Sabalausky (Abscissa) wrote:
> 
> Oh, I didn't mean to imply that I wouldn't love to have it in D (assuming it was all well-fleshed out and didn't have big problems). I just wanted to be crystal clear that I'm merely discussing a langauge design idea here rather than coming in saying "Hey, you people should all like this idea and go implement it put it into D!!!" It's easy for things to get taken that way here, and can result in knee-jerk reactions and otherwise derailing of what's really only intended as a theoretical academic discussion. If something *were* to come of it, and it worked great, and everybody was happy, then fantastic. That's just not what I'm bringing it up for, that's all.

I especially wanted to avoid any the "How dare you even consider speaking of something without fully implementing it first!" that tends to be common here. (Speaking of, *that* sort of thing is far more unprofessional than the mere "bad words" some people are so terrified of).

Am Sun, 9 Jul 2017 16:22:16 -0400
schrieb "Nick Sabalausky (Abscissa)"
<SeeWebsiteToContactMe@semitwist.com>:

> […] a sufficiently-smart compiler could conceivably even choose "runtime" vs "compile-time" (or even, "it varies") based on optimization priorities.

GCC already does this, i.e. find runtime arguments of constant value and generate a second instance of the function with that argument optimized out.

-- 
Marco