And if so is it safe. Without the postblit on X there is no
issue. With the postblit I get that X.__postblit is not callable,
indicating that somehow values are being copied even though my
hope was they would not since it is ref val. Unfortunately const
ref val is not accepted by the compiler.
On 11/15/2012 12:31 PM, Joseph Rushton Wakeling wrote:
On 11/15/2012 01:55 AM, Joseph Rushton Wakeling wrote:
An oddity here: although the correct results seem to come out of the
calculation, at the end, the program containing the parallel foreach hangs -- it
doesn't stop running, even though
On 11/15/2012 03:06 PM, bearophile wrote:
void check() const pure nothrow {
immutable real p = a ^^ 2 + b ^^ 2;
assert(sqrt(p) 10);
}
Is it appropriate to have 'nothrow' given that the assert could fail?
Strive to write D code as much cast-free as possible,
There are times when casting away const is needed. Structs that
define opCast can get in the way of this. For instance, the cast
below fails, but I think it should always be allowed. So, if the
source type and cast type are the same except for const
qualifiers,
there is no need to consider
On 11/14/2012 10:17 PM, Jonathan M Davis wrote:
I would point out though that given how expensive disk writes are, unless
you're doing a lot of work within the parallel foreach loop, there's a good
chance that it would be more efficient to use std.concurrency and pass the
writes to another
Joseph Rushton Wakeling:
Is it appropriate to have 'nothrow' given that the assert could
fail?
Failing asserts produce errors, not exceptions. nothrow only
deals with exceptions. And thankfully in this case your D code
doesn't need to be appropriate, because D refuses nothrow if
the
On 11/15/2012 03:36 PM, bearophile wrote:
Try to avoid casts as much as possible in D, they are a great source for bugs.
Take a look at assumeUnique, or better make your makeFoo pure so its output is
assignable to immutable.
Thanks for the pointer to assumeUnique -- it will be useful, although
On 2012-23-15 15:11, Dan dbdavid...@yahoo.com wrote:
There are times when casting away const is needed. Structs that
define opCast can get in the way of this. For instance, the cast
below fails, but I think it should always be allowed. So, if the
source type and cast type are the same except
On Thursday, November 15, 2012 15:33:31 Joseph Rushton Wakeling wrote:
On 11/14/2012 10:17 PM, Jonathan M Davis wrote:
I would point out though that given how expensive disk writes are, unless
you're doing a lot of work within the parallel foreach loop, there's a
good
chance that it would
On Thursday, November 15, 2012 14:21:41 Dan wrote:
I do not see how copy constructors can help. Receiving const(T)
or const(T) ref to anything and hoping to copy it is the
challenge and doing it from a copy constructor is no easier than
a postblit.
Doing it from a postblit is impossible.
On 11/15/2012 06:24 AM, Joseph Rushton Wakeling wrote:
The practical situation I'm dealing with is that the a struct gets built
inside a function, based on data read from files. Once the data has been
written to the struct, it should never be changed again.
If you don't want the callers be
Again:
http://www.reddit.com/r/programming/comments/138j4t/static_typing_contracts_unit_tests_and_more/
On 11/15/2012 06:40 PM, Ali Çehreli wrote:
b) The user wants to play safe:
auto makeFoo()
{
Foo foo;
foreach (i; 0..10)
foo.add( /* new data point */ );
return foo;
}
void main()
{
immutable foo = makeFoo();
}
Both of those compile with dmd 2.060.
Really? I'm
On Thursday, 15 November 2012 at 17:24:44 UTC, Jonathan M Davis
wrote:
On Thursday, November 15, 2012 14:21:41 Dan wrote:
I do not see how copy constructors can help. Receiving const(T)
or const(T) ref to anything and hoping to copy it is the
challenge and doing it from a copy constructor is no
On 11/15/2012 10:26 AM, Joseph Rushton Wakeling wrote:
On 11/15/2012 06:40 PM, Ali Çehreli wrote:
b) The user wants to play safe:
auto makeFoo()
{
Foo foo;
foreach (i; 0..10)
foo.add( /* new data point */ );
return foo;
}
void main()
{
immutable foo = makeFoo();
}
Both of those compile with
On Thursday, 15 November 2012 at 20:59:37 UTC, Namespace wrote:
Why work this: http://dpaste.dzfl.pl/16a1c912
but not this: http://dpaste.dzfl.pl/6cebb0ad
?
If it is any consolation - the latter does work in 2.061 but not
2.060. It prints:
[0:const(A), 1:const(A)]
Thanks
Dan
On Thursday, 15 November 2012 at 21:25:15 UTC, Dan wrote:
On Thursday, 15 November 2012 at 20:59:37 UTC, Namespace wrote:
Why work this: http://dpaste.dzfl.pl/16a1c912
but not this: http://dpaste.dzfl.pl/6cebb0ad
?
If it is any consolation - the latter does work in 2.061 but
not 2.060. It
On Thursday, November 15, 2012 19:30:03 Dan wrote:
On Thursday, 15 November 2012 at 17:24:44 UTC, Jonathan M Davis
wrote:
On Thursday, November 15, 2012 14:21:41 Dan wrote:
I do not see how copy constructors can help. Receiving const(T)
or const(T) ref to anything and hoping to copy it
On 11/15/2012 07:48 PM, Ali Çehreli wrote:
Do you have a reference type in your struct?
Assuming I do, what can I do to ensure the struct instance is immutable? Is
cast(immutable) now the only option?
On Thursday, November 15, 2012 15:23:40 Dan wrote:
There are times when casting away const is needed. Structs that
define opCast can get in the way of this. For instance, the cast
below fails, but I think it should always be allowed. So, if the
source type and cast type are the same except for
On 11/15/2012 07:43 PM, Kenji Hara wrote:
This code works with dmd git head (and might work with dmd 2.060).
Yes, it works with dmd 2.060 as well.
immutable(Foo) makeFoo() pure
I would like to repeate an earlier question: Does makeFoo() want that
the returned object be immutable? If so,
Thanks, I think I get it. const and postblit don't mix. Copy
ctors don't yet exist but are the hoped for solution to inability
to copy const instances. Copy ctor proposal/solution has not yet
been written up in the newsgroups or details discussed beyond
Andrei and Walter, but have been and
On Friday, November 16, 2012 06:17:55 Dan wrote:
You mention that possibly postblits will go away. That is
discomforting.
It would likely stay around for a very long time for backwards compatibility
and simply be discouraged, but I don't know. Walter is big on backwards
compatilbility though,
23 matches
Mail list logo
