On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky
(Abscissa) wrote:
So, why not encapsulate much of that stuff we merely *describe*
in signatures for generic functions into genuine
honest-to-goodness types?
There would be user-defined symbols, such as "InputRange" or
"SomeString", or "R
On 2017-07-10 22:19, Nick Sabalausky (Abscissa) wrote:
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 mere
Am Sun, 9 Jul 2017 16:22:16 -0400
schrieb "Nick Sabalausky (Abscissa)"
:
> […] 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
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 c
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
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 littl
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 be
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 insta
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
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
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
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
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
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky
(Abscissa) wrote:
Obviously this is all very incomplete, but it's an idea I think
is rather interesting.
You've seen this, right?
https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint
A small step in one such direction, in
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
On 2017-07-10 07:54, Nick Sabalausky (Abscissa) wrote:
On 07/09/2017 09:21 PM, 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 a
On 07/09/2017 09:21 PM, 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 wor
On Sunday, 9 July 2017 at 22:02:51 UTC, Meta wrote:
There's a couple posts he's made here but a lot of it's spread
out across various talks, articles (I think) as well as
newsgroup posts. Here's what I found with a quick google:
https://www.reddit.com/r/cpp/comments/4jqg5z/andrei_alexandresc
On Sunday, 9 July 2017 at 21:59:04 UTC, Nick Sabalausky wrote:
On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:
I'm sorry if I misunderstood what you're proposing, but isn't
this exactly what C++ set out to do with concepts? If that's
the case, I'd recommend you look up some of Andrei's
r
On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:
I'm sorry if I misunderstood what you're proposing, but isn't
this exactly what C++ set out to do with concepts? If that's
the case, I'd recommend you look up some of Andrei's refutation
of concepts in favour of template guards and `static i
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky
(Abscissa) wrote:
On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
> On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
>> return str.join(" ");
>> [...]
>> Error: template std.array.join cannot deduce function from
argument
>> types !()(s
On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
> On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
>> return str.join(" ");
>> [...]
>> Error: template std.array.join cannot deduce function from argument
>> types !()(string, string)
>> [...]
>> simply trying to join a string[] with a separato
22 matches
Mail list logo