On 12/04/2014 10:55 PM, Ellery Newcomer wrote:
I guess tomorrow I can try messing around with thread_attachThis, as the
fullcollect happening in #2 might be screwing with python data. But you
aren't really passing anything from python to d or vice versa, so I'm
not sure why the gc would need to
Joseph Rushton Wakeling:
Yes, I remember you requesting that. Were there ever any PRs,
or was it just spec?
I think two different persons implemented something like "each".
A similar function is used very commonly in F#, where it's named
"iter":
http://msdn.microsoft.com/en-us/library/ee34
map won't actually compute anything until you start asking for
individual elements with front, back, or opIndex.
Personally I like to use something like
ref transform (alias action, R, T...)(ref R range, T addl_args)
{
range = action (range, addl_args);
return range;
}
to
On 06/12/14 00:58, bearophile via Digitalmars-d-learn wrote:
Joseph Rushton Wakeling:
Can anyone advise why,
map is lazy, like most other ranges.
Ah, I see. That function would only be called on consumption of the results of
the map.
Lazy higher order functions like map/filter should b
Joseph Rushton Wakeling:
Can anyone advise why,
map is lazy, like most other ranges.
and whether there's a nice range iteration option to ensure
that this function gets called using each element of the
filteredRange?
Lazy higher order functions like map/filter should be used only
with p
Here's a little experiment I was trying out earlier today in order to try and
convert foreach-style code to using UFCS of ranges:
//
import std.algorithm, std.range, std.stdio;
void main()
{
size_t s = 0;
void essify(size_t n)
{
w
On 06/12/14 00:24, bearophile via Digitalmars-d-learn wrote:
Is this a strong need?
Let's put it this way: I don't mind copy-pasting the same in-contract into
derived class methods. I'd just rather avoid it, and was hoping there was a way
to do so which was trivial.
It's disappointing that
On 05/12/14 23:45, Ali Çehreli via Digitalmars-d-learn wrote:
This is a known problem with contract inheritance. The following bug report
mentions the ugly hack of defining assert(0) as the derived's 'in' contract:
https://issues.dlang.org/show_bug.cgi?id=6856
Thanks for the clarification.
Joseph Rushton Wakeling:
Suppose I have a base class where one of the methods has an
in-contract,
It's named "precondition" or "pre-condition".
Following the example on p.331, I did try calling
super.__in_contract_format(n) (... or
this.Base.__in_contract_format(n) or other variants), but
On 12/05/2014 02:39 PM, Joseph Rushton Wakeling via Digitalmars-d-learn
wrote:
> In other words, the lack of explicit in-contract on Deriv.foo is being
> taken as an _empty_ in-contract, which is being interpreted as per the
> rule that a derived class can have a less restrictive contract than i
Suppose I have a base class where one of the methods has an in-contract, and a
derived class that overrides it:
/
import std.stdio;
abstract class Base
{
abstract void foo(int n)
in
{
assert(n > 5);
}
body
{
assert(
On Friday, 5 December 2014 at 20:38:31 UTC, Gary Willoughby wrote:
How can i check that a type is a struct at compile time? I know
i can test for a class like this:
static if(is(T == class))
{
...
}
But how to do the same thing for a struct?
Same thing but with struct: is(T == struct)
N
How can i check that a type is a struct at compile time? I know i
can test for a class like this:
static if(is(T == class))
{
...
}
But how to do the same thing for a struct?
I have defined LinkedList as di file, Im not compiling it. Im
compiling every .d file separately, eg. main.d -> main.d.o
without including anything else.
I tried to use -femit-templates but nothing happnes.
I dont have object file of LinkedList.di, Im only importing it in
source file and with
On Tuesday, 2 December 2014 at 21:10:33 UTC, Meta wrote:
On Tuesday, 2 December 2014 at 16:38:34 UTC, Mayuresh Kathe
wrote:
While I have been a programmer for close to 23 years, it's
been mostly API level code cobbling work.
Would like to learn "D", but am a bit intimidated by the fact
that I
On Wednesday, 3 December 2014 at 02:41:16 UTC, Shriramana Sharma
via Digitalmars-d-learn wrote:
On Tue, Dec 2, 2014 at 10:45 PM, Mayuresh Kathe via
Digitalmars-d-learn wrote:
Okay, if that is the case, I'll dive into Mr. Alexandrescu's
book as soon as
I get my copy.
BTW, how come all of you ad
thanks a lot. That makes sense.
Kind regards
André
On Friday, 5 December 2014 at 09:29:21 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 05 Dec 2014 09:19:27 +
Andre via Digitalmars-d-learn
wrote:
I think I mimized the coding too much.
What I actually want to achieve is to generat
On Fri, 05 Dec 2014 09:19:27 +
Andre via Digitalmars-d-learn wrote:
> I think I mimized the coding too much.
> What I actually want to achieve is to generate read methods
> in the structure for different data types (Ubyte, short, int):
>
> I thought the eponymous trick would insert the cont
I think I mimized the coding too much.
What I actually want to achieve is to generate read methods
in the structure for different data types (Ubyte, short, int):
I thought the eponymous trick would insert the content of the
enum instead the name itself?
string getReadMethods(string methodName,
19 matches
Mail list logo
