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
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
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
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
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
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 -
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
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.
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
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
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
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 =
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
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
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 want
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
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 openssl
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
29 matches
Mail list logo