On 2012-09-10 01:20, timotheecour wrote:
I'd like to achieve the following:
import std.stdio,std.range,std.algorithm,std.array;
void main(){
auto dg=a=>a*2;
auto a=iota(0,10);
writeln(a.map!dg.array);
}
but this doesn't compile:
Error: variable [...]dg type void is inferred
On 2012-09-10 02:05, Namespace wrote:
I had never problems with that in C++.
If I have members which are const because they are assigned only one
time and needs no other assignment, why should I declare this member not
as const?
In the example I know exactly that I assign only one time a name to
On Monday, September 10, 2012 09:13:04 Jacob Carlborg wrote:
> On 2012-09-10 02:05, Namespace wrote:
> > I had never problems with that in C++.
> > If I have members which are const because they are assigned only one
> > time and needs no other assignment, why should I declare this member not
> > a
On 2012-09-10 09:24, Jonathan M Davis wrote:
And it works just fine in D2. It's const that's the problem. In general, if you
want a member variable to be "read-only" on a struct, I'd strongly advise
using a getter property without a setter property rather than making it const,
because const make
On Monday, September 10, 2012 09:30:59 Jacob Carlborg wrote:
> On 2012-09-10 09:24, Jonathan M Davis wrote:
> > And it works just fine in D2. It's const that's the problem. In general,
> > if you want a member variable to be "read-only" on a struct, I'd strongly
> > advise using a getter property w
On 10/09/12 02:31, Jonathan M Davis wrote:
On Monday, September 10, 2012 02:16:19 Timon Gehr wrote:
Don has expressed the desire to weed those out completely.
If he can do it in a way that leaves in all of the necessary information, then
great, but you need to be able to know what the instanti
On Sunday, 9 September 2012 at 23:54:45 UTC, Jonathan M Davis
wrote:
[SNIP]
the default assignment operator illegal. You could overload it,
and as long as
it doesn't touch any of the const member variables, it would
work, but the
const member variable is stuck as it is, and anything trying to
On Monday, September 10, 2012 11:49:48 monarch_dodra wrote:
> It appears that when writting:
> tests[4] = Test("Foobar");
> It *looks* like compiler is eliding the opAssign/CC completely,
> opting for a bit copy, which is illegal.
As I believe was mentioned elsewhere in this thread, that's due to
Thank you both for your replies, they make perfect sense.
I filed a bug report here:
http://d.puremagic.com/issues/show_bug.cgi?id=8637
On Monday, 10 September 2012 at 09:54:46 UTC, Jonathan M Davis
wrote:
On Monday, September 10, 2012 11:49:48 monarch_dodra wrote:
It appears that when writting:
tests[4] = Test("Foobar");
It *looks* like compiler is eliding the opAssign/CC completely,
opting for a bit copy, which is illegal.
A
Thank you guys, that's fantastic! I'll try out your functions.
On 09/10/12 01:33, timotheecour wrote:
> I'd like to have something like:
> ---
> import std.stdio:!writeln,write;
> ---
> which would import all symbols from std.stdio except the ones listed
> (writeln,write).
>
> Use case:
> The reason is to avoid writing verbose code (specifying all symbols to
I have code:
import std.container;
int main() {
// array
int[] array = [0];
foreach(ref value; array) {
value += 50;
assert(value == 50);
}
foreach(value; array) {
assert(value == 50);
}
// double-linked list;
DList!int dlist;
dlist.insertFront(0);
foreach(ref va
On Monday, 10 September 2012 at 11:18:29 UTC, Alexandr Druzhinin
wrote:
I have code:
import std.container;
int main() {
// array
int[] array = [0];
foreach(ref value; array) {
value += 50;
assert(value == 50);
}
foreach(value; array) {
assert(value == 50);
}
//
On Monday, 10 September 2012 at 11:36:42 UTC, monarch_dodra wrote:
slice.front() = value;//Feed back into the range*
Typo in my code when I was investigating, this should be:
slice.front = value; //Feed back into the range*
On Monday, September 10, 2012 13:37:15 monarch_dodra wrote:
> What bothers *me* though is that the code compiles fine, biting
> more than 1 user in the process.
Which is definitely a bug. If it hasn't been reported, it should be (I suspect
that it has, but I don't know for sure and don't want to
10.09.2012 18:37, monarch_dodra пишет:
There is a know bug: foreach with ref does not currently work these
containers. The reason is that the container's front does not actually
expose a reference, but a value, and that is what is being changed (the
returned value).
There is no hope in sight to
Am Sun, 09 Sep 2012 12:55:19 -0700
schrieb Brad Roberts :
> On 9/9/2012 1:15 AM, Johannes Pfau wrote:
> > Am Sat, 08 Sep 2012 16:25:49 +0100
> > schrieb Russel Winder :
> >
> >> On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote:
> >> […]
> >>> Okay, here:
> >>> https://bitbucket.org/ariovi
Am Mon, 10 Sep 2012 14:48:30 +0200
schrieb Johannes Pfau :
> Sorry, I should have said 'It'll _probably_ never be supported in
> gdc'. There are some possible solutions but:
>
> * It must be good enough to get approved when gdc is merged into gcc.
> (remember it must be portable and gpl and you
On Monday, 10 September 2012 at 12:44:36 UTC, Alexandr Druzhinin
wrote:
10.09.2012 18:37, monarch_dodra пишет:
There is a know bug: foreach with ref does not currently work
these
containers. The reason is that the container's front does not
actually
expose a reference, but a value, and that i
On 09/10/2012 07:07 AM, Ellery Newcomer wrote:
On 09/08/2012 09:01 AM, Timon Gehr wrote:
On 09/08/2012 04:11 PM, Ellery Newcomer wrote:
alias enum int e;
It is valid according to the grammar
I don't believe you. Show me the derivation.
The grammar as shown on dlang.org indeed seems not t
On 09/05/2012 07:10 PM, bearophile wrote:
NumPy arrays <==> D arrays
I've been thinking about this one a bit more, and I am not sure it
belongs in pyd.
First, the conversion is not symmetric. One can convert a numpy.ndarray
to a d array like so:
PyObject* ndarray;
double[][] matrix = d_
Ellery Newcomer:
I've been thinking about this one a bit more, and I am not sure
it belongs in pyd.
I understand. The point of Pyd is to interface D and Python,
while NumPy is something external. So if you find difficulties
just keep it out. Adding it later is possible.
Bye,
bearophile
On 09/10/2012 12:11 PM, bearophile wrote:
I understand. The point of Pyd is to interface D and Python, while NumPy
is something external. So if you find difficulties just keep it out.
Adding it later is possible.
Thing is, pyd will convert a ndarray to d array already, it just won't
do it as
I don't understand how Object.factory could help with
serializing. But what would help is if we did get proper
runtime reflection.
All that'd be needed would be to have Object.factory working with
templates, here's how:
unittest{
class A{}
class B{int x;}
A a=new B;
auto
On Tuesday, 11 September 2012 at 03:18:40 UTC, timotheecour wrote:
So the question is: is that technically impossible or not to
enhance Object.factory in such ways?
Unless someone else wants to correct me, I'm going to say
technically impossible. Object.factory constructs a class at
runtime giv
On Tuesday, 11 September 2012 at 03:18:40 UTC, timotheecour wrote:
auto serialize(T)(T a){
auto
c=cast(SerializerBase)Object.factory("Serializer!("~typeid(a).to!string~").Serializer");
return c.serialize(a);
}
Also, now that I think about it, why couldn't you do this? (it's
equivalen
Also, now that I think about it, why couldn't you do this?
(it's equivalent):
auto serialize(T)(T a) {
auto c = cast(SerializerBase) new Serializer!T;
return c.serialize(a);
}
that won't work with my example:
class A{}
class B:A{int x;}
A a=new B;
auto c=serialize(a); => T is A, but we
On Mon, 2012-09-10 at 15:54 -0700, Ellery Newcomer wrote:
[…]
> Bugger, I'm going to have to go through pyd and replace all usages
> of str with unicode.
Python 2 and Python 3 are totally different in this regard. I don't have
a obvious proposal to make to avoid having PyD for Python 2 and a
di
On Tuesday, 11 September 2012 at 04:47:11 UTC, timotheecour wrote:
Also, now that I think about it, why couldn't you do this?
(it's equivalent):
auto serialize(T)(T a) {
auto c = cast(SerializerBase) new Serializer!T;
return c.serialize(a);
}
that won't work with my example:
class A{}
c
On 2012-09-11 07:57, Chris Cain wrote:
Ah, I see now.
Well regardless, it couldn't be done so conveniently/transparently
because Serializable!B wouldn't exist in the binary unless it was
actually created in code.
Hence proper runtime reflection is needed. I see no way out of this.
--
/Jacob
31 matches
Mail list logo
