Hi !
http://dpaste.dzfl.pl/2fa3dd2ea834
Why S.init not pure ? Is it expected behavior or bug ?
Thanks!
On Friday, 25 April 2014 at 04:23:45 UTC, Ali Çehreli wrote:
On 04/24/2014 08:32 PM, Jeremy DeHaan wrote:
> added the -cov switch to my unit test build
Then you must execute the program. :)
Ali
I did, but still nothing. I even tried using the switch in a
debug build and the same thing happe
On Friday, 25 April 2014 at 07:59:29 UTC, Temtaime wrote:
Hi !
http://dpaste.dzfl.pl/2fa3dd2ea834
Why S.init not pure ? Is it expected behavior or bug ?
Thanks!
Fix
http://dpaste.dzfl.pl/03f73cd958f4
Hi, MrSmith !
Yes, i know that, but my question isn't about it.
I want to type `pure:` at module's beginning and have all
function(in classes, too) declared as pure.
I think `pure:` should do it. But it doesn't.
On Friday, 25 April 2014 at 09:08:50 UTC, Temtaime wrote:
Hi, MrSmith !
Yes, i know that, but my question isn't about it.
I want to type `pure:` at module's beginning and have all
function(in classes, too) declared as pure.
I think `pure:` should do it. But it doesn't.
pure is not a transit
Hi ! Thanks for reply.
Why so ?
And why @nogc not transitive too ?
__traits(getProtection) allows us to know if something is
private, protected, etc. But how would one go about determining
that from another module? The problem here is if module foo
defines a function foofunc that is private, trying to use
__traits(getProtection) from another module fails to co
On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes so
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes some troubles when you use tuples.
Bye,
bearophile
Dicebot:
Why would you even expect those to be same types? These 2 types
are also different:
struct A
{
const int x;
}
alias A_ = const(A);
In general a tuple is a higher level data structure compared to a
struct. So it's not unreasonable to expect a Tuple to be more
flexible than a s
On Friday, 25 April 2014 at 12:17:31 UTC, bearophile wrote:
In general a tuple is a higher level data structure compared to
a struct. So it's not unreasonable to expect a Tuple to be more
flexible than a struct.
Well, wrong :) std.typecons.Tuple IS a struct -
https://github.com/D-Programming-
Dicebot:
Well, wrong :) std.typecons.Tuple IS a struct -
https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388
Nope, that's just an implementation detail. They are two quite
different data structures. Example: slicing a tuple always has a
meaning, while slicing a s
On Friday, 25 April 2014 at 12:42:33 UTC, bearophile wrote:
Dicebot:
Well, wrong :) std.typecons.Tuple IS a struct -
https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388
Nope, that's just an implementation detail. They are two quite
different data structures. Exam
Dicebot:
std.typecons.Tuple is just a subset of all structs implementing
specific behavior. It still acts as struct everywhere when
applicable.
A subset is not the same as the whole set.
You are missing something important about what a data structure
is. Take a look at your computer science
I was just expressing a little frustration :-)
An example; despite it looks simple I am missing something:
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
On Friday, 25 April 2014 at 12:54:25 UTC, bearophile wrote:
Dicebot:
std.typecons.Tuple is just a subset of all structs
implementing specific behavior. It still acts as struct
everywhere when applicable.
A subset is not the same as the whole set.
You are missing something important about wh
Dicebot:
It would be weird exception of general type system rules with
no practical justification I can readily imagine.
I partially disagree. It could be useful to have structural
typing (http://en.wikipedia.org/wiki/Structural_type_system )
only on tuples (and not on structs), because the
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
Foo[] empty;
auto seed = tuple(empty);
reduce!foo(seed, data);
}
I have found a solution:
import
On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes so
Meta:
I think it's a bad idea to make these equal for this reason: if
T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However:
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
assert(is(T1 == T2));
alias UnT1 = Unqual!T1; // Tuple!(int, int)
alias UnT2 = Unq
On Friday, 25 April 2014 at 13:18:13 UTC, bearophile wrote:
Dicebot:
It would be weird exception of general type system rules with
no practical justification I can readily imagine.
I partially disagree. It could be useful to have structural
typing (http://en.wikipedia.org/wiki/Structural_typ
Fibers are more lightweight, they're not kernel objects. Threads
are scheduled by kernel (usually). Fibers are better if you can
get better resource usage with manual scheduling - less context
switches, or don't want to consume resources need by threads.
On Saturday, 12 April 2014 at 10:41:19 UTC, hicman wrote:
will the library build for x64?
It will build but not true x64.
On Friday, 11 April 2014 at 12:33:27 UTC, FrankLike wrote:
On Thursday, 14 November 2013 at 16:17:53 UTC, Heinz wrote:
You have to manually set the tooltip's max width t
On Fri, 2014-04-25 at 17:10 +, Kagamin via Digitalmars-d-learn
wrote:
> Fibers are more lightweight, they're not kernel objects. Threads
> are scheduled by kernel (usually). Fibers are better if you can
> get better resource usage with manual scheduling - less context
> switches, or don't wa
On Thursday, 14 November 2013 at 16:17:53 UTC, Heinz wrote:
You have to manually set the tooltip's max width to a fixed
value using the tooltip handle and Win32 API, by doing this
you're telling the tooltip object it is a multiline tooltip and
from now on it will accept \r\n as end of line:
hi everyone.
I'm trying to symmetrically encrypt some text using the openssl
bindings. My code compiles and fails silently. Clearly there is
something very wrong with it - it could be my novice D skills, or
my misuse of the openssl binding.
auto chunk = new ubyte[](16);
foreach(ref x
On Fri, 25 Apr 2014 19:06:31 +, brad clawsie wrote:
> hi everyone.
>
> I'm trying to symmetrically encrypt some text using the openssl
> bindings. My code compiles and fails silently. Clearly there is
> something very wrong with it - it could be my novice D skills, or my
> misuse of the opens
Justin Whear:
brad clawsie:
b = cast(ubyte[]) s;
Better to use std.string.representation.
It doesn't look like you're allocating space for `e` or `d`,
e.g. `auto e
= new ubyte[](256);`, so those arrays have a length of 0, in
which case
the encrypt/decrypt functions are just trashing
Dicebot:
For your objections to make sense tuple would need to be
inroduced as completely new first class type system entity. As
this will never happen,
I think first class tuples will happen in D, because the current
tuple situation is quite bad.
But this thread is not about built-in tupl
On 04/22/2014 11:45 AM, monarch_dodra wrote:
> Reduce returns "the seed". It's actually doing something more like this:
>
> int[1] foo()
> {
> int[1] sum
> sum = sum[]; //The lambda operates, and the
> //result is assigned back to the seed.
> return sum; //Returns
30 matches
Mail list logo
