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 22:20:02 UTC, Adam D. Ruppe wrote:
Eh, that's not really why... this is just a crappy
implementation. We can do a lot better with the library and a
lot better with the compiler without losing any of the
genericness.
But the more powerful the generics are, the harder
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 Sunday, 9 July 2017 at 14:22:45 UTC, John Colvin wrote:
That said, it would be nice if the errors were less daunting
somehow.
Better template constraint errors are on our Agenda for later
this year.
https://wiki.dlang.org/Vision/2017H2_draft
On Sunday, 9 July 2017 at 17:13:11 UTC, Dukc wrote:
About C++ from what I've heard, generic error messages there
are not only much worse than others, they are much worse than
even D template errors!
Yeah. You don't want to try reading the GCC message for a
std::cout error. It's like 80 lines
is at least has some merit
anyway. Hell, call it "concepts++" or "concepts, the D way" (note: I'm
NOT pitching this as a suggestion for something D should do. Not saying
D should or should'nt, just speaking purely in the realm of "langauge
design brainstormin
ncepts++" or "concepts, the D way" (note: I'm
NOT pitching this as a suggestion for something D should do. Not saying
D should or should'nt, just speaking purely in the realm of "langauge
design brainstorming" here...Just because it's been on my mind an
On 07/09/2017 06:12 PM, Adam D. Ruppe wrote:
On Sunday, 9 July 2017 at 17:07:16 UTC, bitwise wrote:
I suppose I'm biased, and PHP/Python have a fair following, but after
a few years of PHP coding (part time as part of a larger project) I'm
not sure I will ever make a full psychological recovery
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 17:13:11 UTC, Dukc wrote:
To answer the part "why" about them sucking, is that they are
generic.
Eh, that's not really why... this is just a crappy
implementation. We can do a lot better with the library and a lot
better with the compiler without losing any of the ge
On Sunday, 9 July 2017 at 17:07:16 UTC, bitwise wrote:
I suppose I'm biased, and PHP/Python have a fair following, but
after a few years of PHP coding (part time as part of a larger
project) I'm not sure I will ever make a full psychological
recovery..
PHP actually is one of the languages tha
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
On Sunday, 9 July 2017 at 13:26:31 UTC, Adam D. Ruppe wrote:
The error message sucks, but you clearly have a string when you
meant string[].
To answer the part "why" about them sucking, is that they are
generic.
Were join() just a regular function taking two strings, or two
interfaces which
On Sunday, 9 July 2017 at 13:26:31 UTC, Adam D. Ruppe wrote:
strip is used by Python and Ruby too... of the languages i
know, it is about half a half.
BTW if you are ever searching, try my website:
http://dpldocs.info/trim
I find this part of D very annoying as well.
D looks like a C langua
On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
import string.
...
return str.join(" ");
gives
Error: template std.array.join cannot deduce function from
argument types !()(string, string)
Well there's your mistake? There is no function `join` that takes
(string, string). Everyth
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 separator.
The error message sucks, but you clearly have a string wh
On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
[...]
Your example is incomplete but this literally works for me.
import std.stdio;
import std.string;
void main()
{
string[] words = [ "hello", "world", "!" ];
writeln(words.join(" "));
}
You probably passed a string instead o
import std.array;
import std.stdio;
void main() {
string[] strs = ["abc", "def"];
writeln(strs.join(" "));
}
Works fine?
import string.
...
return str.join(" ");
gives
Error: template std.array.join cannot deduce function from
argument types !()(string, string), candidates are:
\..\..\src\phobos\std\array.d(1591):std.array.join(RoR,
R)(RoR ror, scope R sep) if (isInputRange!RoR &&
isInputRange!(Unqual
35 matches
Mail list logo
