Hi folks,
it was really good and productive discussion on const and
immutability,
special thanks for those (Jonatan,Steven,Cris,etc) who answered
hard Mehrad's questions and clarified so important topics.
Can I kindly ask you folks to update FAQ on the site to have
ability for newcomers to
On Thursday, 3 May 2012 at 13:40:41 UTC, Steven Schveighoffer
wrote:
On Wed, 02 May 2012 12:59:34 -0400, David Nadlinger
wrote:
Additionally, shared is currently little more than a marker
for non-TLS data.
No, it's very important that it is a type constructor. For
example, it makes weak-pur
On Wed, 02 May 2012 12:59:34 -0400, David Nadlinger
wrote:
On Wednesday, 2 May 2012 at 16:52:33 UTC, Alex Rønne Petersen wrote:
shared? Almost always in any non-trivial application. shared is only
useful if you're dealing with templatized functions that can actually
handle it, which is no
Okay, that's for shared.
What about const though?
On Wednesday, May 02, 2012 13:30:11 Mehrdad wrote:
> Okay thanks for the replies, that clears up a bunch of things for me.
>
> Regarding the last part:
>
> Yes, it 'works'. The only trouble is that you can never set the interface
> methods to be 'const', because any sort of indirection can screw
On 2012-05-02 20:58, Mehrdad wrote:
Er, I guess I didn't say what I actually meant to say, my bad. x_x
What I meant that you're assuming that derived classes won't need
mutable state in an const method that they overrode.
Yes, that would be the assumption. It's not possible without subverting
On Wednesday, 2 May 2012 at 20:30:10 UTC, Mehrdad wrote:
Okay thanks for the replies, that clears up a bunch of things
for me.
No problem, I'm glad it's helping.
Regarding the last part:
Yes, it 'works'. The only trouble is that you can never set the
interface methods to be 'const', because
"Timon Gehr" wrote in message news:jns5du$64q$1...@digitalmars.com...
On 05/02/2012 08:58 PM, Mehrdad wrote:
> mutable state in an const method
=O
a*
Okay thanks for the replies, that clears up a bunch of things for me.
Regarding the last part:
Yes, it 'works'. The only trouble is that you can never set the interface
methods to be 'const', because any sort of indirection can screw you over
later. This is why const is less useful than it cou
On 05/02/2012 08:58 PM, Mehrdad wrote:
mutable state in an const method
=O
On Wednesday, 2 May 2012 at 15:35:15 UTC, Mehrdad wrote:
I guess this answers my question then: const/immutable are
useful for multithreading.
Indeed, const/immutable makes multithreading much better. It
provides restrictions which make it much easier to think about
problems. If I pass a const
On Wednesday, May 02, 2012 11:58:41 Mehrdad wrote:
> Er, I guess I didn't say what I actually meant to say, my bad. x_x
>
> What I meant that you're assuming that derived classes won't need mutable
> state in an const method that they overrode.
If a const function needs mutable member variables o
Er, I guess I didn't say what I actually meant to say, my bad. x_x
What I meant that you're assuming that derived classes won't need mutable
state in an const method that they overrode.
On 2012-05-02 18:01, Mehrdad wrote:
When you're making the object 'const', you're not making the
assumption that no one who derives from this class need mutable state.
What you're doing is asserting that bits belonging to this object
needs to be 'const' to preserve sequential consistency across t
This is a false choice. The performance of Java strings (BTW, which I
don't think is that bad) is not tied to whether they are immutable or not.
Oh yes, I think you're right. If I remember, someone told me Java strings
don't re-copy data when you substring; I forgot about that.
But that's de
But that's definitely not the case in C#.
(which, I should clarify, was what implicitly came to my mind as an example
of immutable strings)
On Wed, May 02, 2012 at 07:21:46PM +0200, bearophile wrote:
> H. S. Teoh:
>
> >One area where I'd like const to be improved, though, is a way to
> >indicate that const-ness depends on the arguments, specifically, on
> >the behaviour of a delegate argument.
>
> There was a long discussion about th
H. S. Teoh:
One area where I'd like const to be improved, though, is a way
to indicate that const-ness depends on the arguments,
specifically, on the behaviour of a delegate argument.
There was a long discussion about this, with proposals like
@pure(compile_time_predicate) to define a condit
On Wednesday, 2 May 2012 at 16:52:33 UTC, Alex Rønne Petersen
wrote:
shared? Almost always in any non-trivial application. shared is
only useful if you're dealing with templatized functions that
can actually handle it, which is not the case as often as one
would like.
Additionally, shared is
On 02-05-2012 17:58, Mehrdad wrote:
Could someone mention a case where it is __necessary__ to cast away
const()?
How about immutable()?
How about shared()?
shared? Almost always in any non-trivial application. shared is only
useful if you're dealing with templatized functions that can actually
On Wednesday, 2 May 2012 at 15:21:31 UTC, Mehrdad wrote:
"Steven Schveighoffer" wrote in message
news:op.wdokh6vteav7ka@localhost.localdomain...
But many languages that *don't* have const/immutable do well
with this pattern (think Java strings).
Java strings are pretty poor for performance
When you're making the object 'const', you're not making the assumption
that no one who derives from this class need mutable state.
What you're doing is asserting that bits belonging to this object needs to
be 'const' to preserve sequential consistency across threads or for other
reasons.
Bits
On 2012-05-02 15:13:43 +, "Mehrdad" said:
Yes, 'const' is part of the interface.
The trouble is that when you make it part of the interface, you're
making the assumption that **no one** who derives from your class will
need mutable state.
How can you ever guarantee that?
When you're
Could someone mention a case where it is __necessary__ to cast away const()?
How about immutable()?
How about shared()?
"Chris Cain" wrote in message news:wyqyigxytaqwwmhfh...@forum.dlang.org...
If you want just to specify that (and not ask the compiler to check for
you), documentation will do.
Heh, if only the world was so ideal...
That's _any_ kind of modification of state. If you change state, you can't
us
On Wed, May 02, 2012 at 05:16:26PM +0200, bearophile wrote:
> H. S. Teoh:
>
> >Doesn't it already?
>
> Right, this:
>
> class Foo {}
> void main() @safe {
> const f1 = new Foo;
> auto f2 = cast(Foo)f1;
> }
>
>
> Gives:
> test.d(5): Error: cast from const(Foo) to test.Foo not allowed
"Steven Schveighoffer" wrote in message
news:op.wdokh6vteav7ka@localhost.localdomain...
There are two solutions, both are horrible.
That's what scares me lol
There is a possible 3rd solution. Don't use immutable/const, instead use
information hiding.
In other words, Your class is already te
H. S. Teoh:
Doesn't it already?
Right, this:
class Foo {}
void main() @safe {
const f1 = new Foo;
auto f2 = cast(Foo)f1;
}
Gives:
test.d(5): Error: cast from const(Foo) to test.Foo not allowed in
safe code
Bye,
bearophile
All of that might hold if the compiler could actually make optimizations
based on the knowledge that an integer wouldn't overflow. But what
optimizations could it make?
Look for "signed integer overflow" here.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
Yes, 'const' is part of the interface.
The trouble is that when you make it part of the interface, you're making
the assumption that **no one** who derives from your class will need mutable
state.
How can you ever guarantee that?
On Wed, May 02, 2012 at 09:57:58AM -0400, Andrei Alexandrescu wrote:
[...]
> Casting away const should be statically disallowed in @safe code.
[...]
Doesn't it already?
T
--
Everybody talks about it, but nobody does anything about it! -- Mark Twain
Mehrdad:
"Lazy-loading" and caching aren't exactly obscure or
rarely-used concepts -- which seems to be the way they are
portrayed here. They are *bound* to be used in any nontrivial
program.
Right.
- - - - - - - - - -
Andrei Alexandrescu:
Casting away const should be statically disallow
On 5/2/12 3:10 AM, Mehrdad wrote:
Whoa, what?
So you're saying
"X results in UB"
means
"Compiler guarantees X"
?
By that philosophy, C and C++ are orders of magnitude better than D,
given how many so-called "guarantees" they make about your code...
Casting away const should be statically dis
On Wednesday, 2 May 2012 at 12:19:35 UTC, Jacob Carlborg wrote:
For D, it's not limited to the public interface. The rules
apply to ALL methods and fields.
Indeed. I may have forgot to add "in any way shape form or
fashion" to that particular line, but it's important to node that
const means
On Tue, 01 May 2012 23:30:27 -0400, Mehrdad wrote:
Also, I think you didn't notice the other problem.
The other problem was with IConnection, whose send() wasn't 'const',
which also gives you an error due to the transitivity of const (which
I've also claimed is broken).
And how could it? I
On 2012-05-02 13:41, Chris Cain wrote:
If that's what you want, then that's precisely what D does. "According
to the public interface of Student, none of the methods I will use will
modify the object." As opposed to C++'s method of "According to the
public interface of student, these methods hav
On Wednesday, 2 May 2012 at 06:10:04 UTC, Mehrdad wrote:
I don't think you answered my question.
What I said (or meant to ask) was this:
- OK, FINE, let's say I don't know what D's const() means,
then. Maybe it isn't suitable for what I need. I just want to
know:
_How do you specify that the
On 05/02/2012 10:26 AM, Jonathan M Davis wrote:
All of that might hold if the compiler could actually make optimizations based
on the knowledge that an integer wouldn't overflow. But what optimizations
could it make?
x+1 > x ==> true
On Wednesday, May 02, 2012 01:06:47 Mehrdad wrote:
> You can replace "signed integer overflow" with pretty much whatever
> 'guarantee' in C that suits your fancy.
> See below.
>
>
> "Jonathan M Davis" wrote in message
> news:mailman.207.1335944070.24740.digitalmar...@puremagic.com...
>
> > I do
On Wednesday, May 02, 2012 01:12:15 Mehrdad wrote:
> > > Wouldn't "physical" const-ness be an implementation detail of the
> > > object, and therefore, impossible to determine by the user of the
> > > object?
> >
> > No, it's not an implementation detail. When you mark an object as being
> > physi
On 05/02/2012 08:48 AM, Mehrdad wrote:
In the world of OOP,
interface Readonly{
auto read(){ ... }
}
class Mutable{
auto read(){ ... }
void write(int x){ ... }
Readonly getReadonly(){ ... }
}
private class Adapter: Readonly{
Mutable field;
auto read(){ return field.re
> Wouldn't "physical" const-ness be an implementation detail of the
> object, and therefore, impossible to determine by the user of the
> object?
No, it's not an implementation detail. When you mark an object as being
physically const, then you're guaranteeing that you will not alter it
through
You can replace "signed integer overflow" with pretty much whatever
'guarantee' in C that suits your fancy.
See below.
"Jonathan M Davis" wrote in message
news:mailman.207.1335944070.24740.digitalmar...@puremagic.com...
I don't follow.
Let's see if this is better.
The D compiler guarantees
On Wednesday, 2 May 2012 at 06:44:30 UTC, Mehrdad wrote:
Whether the compiler makes **GUARANTEES** about code is
_irrelevant_ to whether or not the language uses 'const' to
improve performance.
You could very well have a language which **enforces**
const-ness (i.e. doesn't prevent casting it
On Wednesday, May 02, 2012 00:10:33 Mehrdad wrote:
> Whoa, what?
>
> So you're saying
> "X results in UB"
> means
> "Compiler guarantees X"
> ?
>
>
> By that philosophy, C and C++ are orders of magnitude better than D, given
> how many so-called "guarantees" they make about your code..
Whoa, what?
So you're saying
"X results in UB"
means
"Compiler guarantees X"
?
By that philosophy, C and C++ are orders of magnitude better than D, given
how many so-called "guarantees" they make about your code...
On Tuesday, May 01, 2012 23:48:29 Mehrdad wrote:
> In the world of OOP, when would "guarantee"ing (so to speak) 'physical'
> const-ness ever be handy?
>
> Wouldn't "physical" const-ness be an implementation detail of the object,
> and therefore, impossible to determine by the user of the object?
On Tuesday, May 01, 2012 23:44:30 Mehrdad wrote:
> You said:
> "In C++, the compiler can't use it to provide any real **guarantees**..."
>
> Now you're telling me D doesn't guarantee it either.
> And then go on telling me about how D uses const-ness to make assumptions
> and improve performance.
>
... i.e. doesn't prevent casting it away)
Typo, I meant "DOES prevent"
You said:
"In C++, the compiler can't use it to provide any real **guarantees**..."
Now you're telling me D doesn't guarantee it either.
And then go on telling me about how D uses const-ness to make assumptions
and improve performance.
Isn't your answer orthogonal to your claim? o.O
Whether t
In the world of OOP, when would "guarantee"ing (so to speak) 'physical'
const-ness ever be handy?
Wouldn't "physical" const-ness be an implementation detail of the object,
and therefore, impossible to determine by the user of the object?
On Tuesday, May 01, 2012 23:10:04 Mehrdad wrote:
> "Chris Cain" wrote in message news:nqgwunggifrgmwwhk...@forum.dlang.org...
>
> > What about the object do you want const? How should this object normally
> > change things? It looks like the way you've coded it, your connection will
> > get infor
On Tuesday, May 01, 2012 23:14:06 Mehrdad wrote:
> > In C++, the compiler can't use it to provide any real guarantees, because
> > the programmer is free to violate const at any time via mutable or casting
> > away const.
>
> Maybe I'm being stupid, but how is the case any different in D?
D's typ
In C++, the compiler can't use it to provide any real guarantees, because
the programmer is free to violate const at any time via mutable or casting
away const.
Maybe I'm being stupid, but how is the case any different in D?
"Chris Cain" wrote in message news:nqgwunggifrgmwwhk...@forum.dlang.org...
What about the object do you want const? How should this object normally
change things? It looks like the way you've coded it, your connection will
get information off of a server.
I don't think you answered my questio
On Wednesday, 2 May 2012 at 04:18:18 UTC, Chris Cain wrote:
... specify that one of those students has a read-only
connection. Something like Student!StudentDBConnection might
work, and then maybe Student!const(StudentDBConnection).
I take the second one back, I've not written any kind of
con
On Tuesday, May 01, 2012 21:05:11 Mehrdad wrote:
> Okay, so let's say you're right
>
> void process1(Student s) { .. }
> void process2(const(Student) s) { ... }
>
> and that what I guess what I REALLY want is to say, "process1() won't
> change the student's name, birthday, or any other a
On Wednesday, 2 May 2012 at 04:05:11 UTC, Mehrdad wrote:
Okay, so let's say you're right
void process1(Student s) { .. }
void process2(const(Student) s) { ... }
and that what I guess what I REALLY want is to say,
"process1() won't change the student's name, birthday, or any
other attri
Okay, so let's say you're right
void process1(Student s) { .. }
void process2(const(Student) s) { ... }
and that what I guess what I REALLY want is to say, "process1() won't
change the student's name, birthday, or any other attribute, but process2()
will".
How do you propose I make th
On Wednesday, 2 May 2012 at 03:22:40 UTC, Mehrdad wrote:
Yes, that's **exactly** why I've said 'const is broken' for at
least a year now, but it seemed like people objected to my
conclusion...
The trouble, as I just showed, is that it isn't.
"Lazy-loading" and caching aren't exactly obscure or
Also, I think you didn't notice the other problem.
The other problem was with IConnection, whose send() wasn't 'const', which
also gives you an error due to the transitivity of const (which I've also
claimed is broken).
And how could it? It's just a connection, not a server, so it doesn't parse
On Tuesday, May 01, 2012 20:22:40 Mehrdad wrote:
> 1. Wouldn't your solution
>(a) Be telling the programmer, "you *can't* lazy-load const objects"?
>(b) Require duplicating the code 3 times? (Yes, you can factor it out as
> a mixin, but who wants to do that??)
>
> 2. "Some folks that like
1. Wouldn't your solution
(a) Be telling the programmer, "you *can't* lazy-load const objects"?
(b) Require duplicating the code 3 times? (Yes, you can factor it out as
a mixin, but who wants to do that??)
2. "Some folks that like lazy loading such as this seem to have come to the
conclusi
Mehrdad:
Notice that there are two const-related issues in the code that
are literally *unsolvable* (unless you avoid const/immutable
entirely, or unless you cast() -- but then your entire code
would be filled with dangerous const casts...).
Casting away casts is rather dangerous in D (more
On Tuesday, May 01, 2012 18:55:03 Mehrdad wrote:
> Let's say you have this hypothetical piece of code:
>
> interface IConnection { string send(string data); }
> class Student
> {
> private string id;
> private string cachedName;
> private IConnection conn;
>
> public this(string i
Let's say you have this hypothetical piece of code:
interface IConnection { string send(string data); }
class Student
{
private string id;
private string cachedName;
private IConnection conn;
public this(string id) { this.id = id; this.conn = ...; }
public @property string name()
On Sunday, 11 December 2011 at 04:16:04 UTC, Mehrdad wrote:
Moar bugs/ICEs...
struct S(int N) { this(T!N) { } }
alias S!1 M;
annoy.d(1): Error: template instance T!(N) template 'T' is not
defined, did you mean M?
annoy.d(1): Error: T!(N) is used as a type
ty = 35
Assertion failure: '0
On Sunday, 11 December 2011 at 04:27:31 UTC, Mehrdad wrote:
Another bug, this time regarding invariant()
(I think this is related to the previous one about int vs.
size_t in template parameters, but I'm not sure...)
template NArray(T, size_t N)
{ static if (N > 0) { alias NArray!(
On Saturday, 10 December 2011 at 19:43:51 UTC, Mehrdad wrote:
Oh, nice, here's an ICE for y'all :)
No more ICE on 2.059 :)
On Saturday, 10 December 2011 at 10:34:28 UTC, Mehrdad wrote:
... and another...
struct Matrix(T, size_t N = 1)
{ public auto mul(Matrix!(T, N) other) const { return this; } }
void main()
{
Matrix!(int, 2) m;
m.mul(m);
}
annoy.d(7): Error: function annoy.Matrix!(int,2).Matrix.mul
(Mat
On Saturday, 28 April 2012 at 09:26:36 UTC, SomeDude wrote:
On Saturday, 10 December 2011 at 09:50:27 UTC, Timon Gehr wrote:
On 12/10/2011 10:43 AM, Mehrdad wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6809
This one now works (I just updated the issue), but the bug with
reduce! is st
On Saturday, 10 December 2011 at 09:50:27 UTC, Timon Gehr wrote:
On 12/10/2011 10:43 AM, Mehrdad wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6809
This one now works (I just updated the issue), but the bug with
reduce! is still open.
On 12/13/2011 01:58 AM, Jesse Phillips wrote:
On Sun, 11 Dec 2011 19:40:42 +0100
Mafi wrote:
void f(ref const(int)* a, const(int)* b) {a = b; }
void main() {
immutable(int)* a;
auto b = (new int[](5)).ptr;
f(a, b);
//if this compiles I have just assigned a mutable pointer
/
On Sun, 11 Dec 2011 19:40:42 +0100
Mafi wrote:
> void f(ref const(int)* a, const(int)* b) {a = b; }
> void main() {
>immutable(int)* a;
>auto b = (new int[](5)).ptr;
>f(a, b);
>//if this compiles I have just assigned a mutable pointer
>//to an immutable one
> }
>
> With the a
On Monday, December 12, 2011 12:13:54 Kai Meyer wrote:
> On 12/10/2011 03:52 AM, Timon Gehr wrote:
> > On 12/10/2011 11:45 AM, bearophile wrote:
> >> Timon Gehr:
> >>> Just slice the const array to get a range. The specialization for
> >>> ranges does not have the bug.
> >>>
> >>> import std.algor
On 12/10/2011 03:52 AM, Timon Gehr wrote:
On 12/10/2011 11:45 AM, bearophile wrote:
Timon Gehr:
Just slice the const array to get a range. The specialization for ranges
does not have the bug.
import std.algorithm;
void main() {
const arr = [1, 2, 3];
reduce!"a*b"(arr[]); // It works.
}
Wasn
On Mon, 12 Dec 2011 12:49:11 -0500, Timon Gehr wrote:
On 12/12/2011 05:46 PM, Steven Schveighoffer wrote:
I still am uneasy with
allowing applying a wildcard to a reference underneath to mutable
references. I know it doesn't work for const.
There is nothing being applied, inout is just mat
On 12/12/2011 05:46 PM, Steven Schveighoffer wrote:
On Mon, 12 Dec 2011 10:21:35 -0500, Timon Gehr wrote:
On 12/12/2011 04:08 PM, Timon Gehr wrote:
On 12/12/2011 03:46 PM, Timon Gehr wrote:
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
On Mon, 12 Dec 2011 10:21:35 -0500, Timon Gehr wrote:
On 12/12/2011 04:08 PM, Timon Gehr wrote:
On 12/12/2011 03:46 PM, Timon Gehr wrote:
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/
On 12/12/2011 04:08 PM, Timon Gehr wrote:
On 12/12/2011 03:46 PM, Timon Gehr wrote:
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed
On 12/12/2011 03:46 PM, Timon Gehr wrote:
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or e.
On 12/12/2011 01:50 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or e.g.
here, a
matrix)? Copy/paste the code for
On Sun, 11 Dec 2011 12:07:37 -0500, Mafi wrote:
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or e.g.
here, a
matrix)? Copy/paste the code for const- and non-const versions?
Internal to a funct
On 11/12/11 06:55, Jonathan M Davis wrote:
On Saturday, December 10, 2011 05:45:11 bearophile wrote:
Timon Gehr:
Just slice the const array to get a range. The specialization for ranges
does not have the bug.
import std.algorithm;
void main() {
const arr = [1, 2, 3];
reduce!"a*b"(
Am 11.12.2011 20:35, schrieb Andrei Alexandrescu:
On 12/11/11 12:40 PM, Mafi wrote:
void f(ref const(int)* a, const(int)* b) {a = b; }
void main() {
immutable(int)* a;
auto b = (new int[](5)).ptr;
f(a, b);
//if this compiles I have just assigned a mutable pointer
//to an immutable one
}
immuta
On 12/11/2011 08:35 PM, Andrei Alexandrescu wrote:
On 12/11/11 12:40 PM, Mafi wrote:
void f(ref const(int)* a, const(int)* b) {a = b; }
void main() {
immutable(int)* a;
auto b = (new int[](5)).ptr;
f(a, b);
//if this compiles I have just assigned a mutable pointer
//to an immutable one
}
immut
On 12/11/11 12:40 PM, Mafi wrote:
void f(ref const(int)* a, const(int)* b) {a = b; }
void main() {
immutable(int)* a;
auto b = (new int[](5)).ptr;
f(a, b);
//if this compiles I have just assigned a mutable pointer
//to an immutable one
}
immutable(int)* does not convert to immuta
Am 11.12.2011 19:00, schrieb Walter Bright:
On 12/11/2011 9:07 AM, Mafi wrote:
But what about:
void f(ref inout(int)* a, inout(int)* b) { a = b; }
This cant work with const because that would violate the const system.
I think
the rule should be that either the return type must be inout or at
lea
On 12/11/2011 9:07 AM, Mafi wrote:
But what about:
void f(ref inout(int)* a, inout(int)* b) { a = b; }
This cant work with const because that would violate the const system. I think
the rule should be that either the return type must be inout or at least one
ref/out parameter.
Am I overlooking so
Am 10.12.2011 21:25, schrieb Walter Bright:
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or e.g.
here, a
matrix)? Copy/paste the code for const- and non-const versions?
Internal to a function, inout behaves like 'const'. You won't be able
On Sat, 10 Dec 2011 14:47:15 -0500, Mehrdad wrote:
On 12/10/2011 3:33 AM, Walter Bright wrote:
On 12/10/2011 3:14 AM, Mehrdad wrote:
... and another... (yes, this one _IS_ a const issue)
struct S { int opApply(scope int delegate(ref inout(int)) dg) inout {
return 0; } }
void main()
{
fore
Another bug, this time regarding invariant()
(I think this is related to the previous one about int vs. size_t in
template parameters, but I'm not sure...)
template NArray(T, size_t N)
{ static if (N > 0) { alias NArray!(T, N - 1)[] NArray; } else {
alias T NArray; } }
struct
Moar bugs/ICEs...
struct S(int N) { this(T!N) { } }
alias S!1 M;
annoy.d(1): Error: template instance T!(N) template 'T' is not defined,
did you mean M?
annoy.d(1): Error: T!(N) is used as a type
ty = 35
Assertion failure: '0' on line 145 in file 'mtype.c
On 12/10/2011 10:04 PM, Mehrdad wrote:
On 12/10/2011 1:00 PM, Timon Gehr wrote:
Yah, the issue is that *BOTH* your inouts are on a parameter. Just
change them to const, without copying any code and call it a day...
I don't see what's wrong with that, but yes, that's what I did. And that
caused
On 12/10/2011 1:00 PM, Timon Gehr wrote:
Yah, the issue is that *BOTH* your inouts are on a parameter. Just
change them to const, without copying any code and call it a day...
I don't see what's wrong with that, but yes, that's what I did. And that
caused the next bug that I posted. :P
Jonathan M Davis:
> Per isInputRange!(typeof(arr)), no. It has the right functions, but it can't
> use them, because it's const.
> [... snip]
>
> Ranges are too heavily used
> with their current API for us to change it that drastically now.
Thank you Jonathan for taking the time to explain me
On 12/10/2011 08:47 PM, Mehrdad wrote:
On 12/10/2011 3:33 AM, Walter Bright wrote:
On 12/10/2011 3:14 AM, Mehrdad wrote:
... and another... (yes, this one _IS_ a const issue)
struct S { int opApply(scope int delegate(ref inout(int)) dg) inout {
return 0; } }
void main()
{
foreach (i; S()) { }
On 12/10/2011 12:27 PM, Walter Bright wrote:
On 12/10/2011 1:37 AM, Mehrdad wrote:
(Sorry for being so critical but at least I tried to make it
constructive...)
Actually, I think your post is very constructive and worthwhile.
Thanks for taking the time to be specific about what issues you're
On 12/10/2011 1:37 AM, Mehrdad wrote:
(Sorry for being so critical but at least I tried to make it constructive...)
Actually, I think your post is very constructive and worthwhile. Thanks for
taking the time to be specific about what issues you're running in to.
On 12/10/2011 11:03 AM, Mehrdad wrote:
So how are you supposed to implement opApply on a container (or e.g. here, a
matrix)? Copy/paste the code for const- and non-const versions?
Internal to a function, inout behaves like 'const'. You won't be able to modify
the data. Therefore, if there is n
1 - 100 of 149 matches
Mail list logo
