On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
I'm of the view that code should only require the minimum of
assumptions
it needs to actually work. If your code can work with mutable
types,
then let it take a mutable (unqualified) type. If your code
works
without modifying
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
I'm of the view that code should only require the minimum of
assumptions
it needs to actually work. If your code can work with mutable
types,
then let it take a mutable (unqualified) type. If your code
works
without modifying
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 09:45:09PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
[...]
I think any usage of immutable with types/entities not
initially
designed for immutability is
On Thu, Oct 17, 2013 at 08:56:08AM +0200, qznc wrote:
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
I'm of the view that code should only require the minimum of
assumptions it needs to actually work. If your code can work with
mutable types, then let it take a mutable
On Thu, Oct 17, 2013 at 09:08:16AM +0200, qznc wrote:
On Wednesday, 16 October 2013 at 20:33:23 UTC, H. S. Teoh wrote:
I'm of the view that code should only require the minimum of
assumptions it needs to actually work. If your code can work with
mutable types, then let it take a mutable
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
I'm reviewing Ali's insightful presentation from 2013 DConf. I
wonder has he or anyone else followed up on the concepts or
formalized some guidelines that could achieve consensus. I
definitely agree it would be helpful to
On 10/16/2013 10:23 AM, Daniel Davidson wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson wrote:
guidelines):
1. If a variable is never mutated, make it const, not immutable.
2. Make the parameter reference to immutable if that is how you will
use it anyway. It is fine
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson wrote:
[...]
Maybe it is a philosophical question, but where does immutability
really come from? Is it an aspect of some piece of data or is it a
promise that function
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
[...]
Maybe it is a philosophical question, but where does
immutability
really come from? Is
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
Maybe it's helpful to understand how D's const system works. The
following diagram may help (please excuse the ASCII graphics):
const
/ \
mutable immutable
I think people in this
On Wed, Oct 16, 2013 at 08:49:51PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson wrote:
[...]
If you have a type that has now or may ever have in the future any
mutable aliasing (e.g.
On Wednesday, 16 October 2013 at 18:52:23 UTC, qznc wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
Maybe it's helpful to understand how D's const system works.
The
following diagram may help (please excuse the ASCII graphics):
const
/
On Wed, Oct 16, 2013 at 08:52:22PM +0200, qznc wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh wrote:
Maybe it's helpful to understand how D's const system works. The
following diagram may help (please excuse the ASCII graphics):
const
/ \
On Wednesday, 16 October 2013 at 19:06:06 UTC, Daniel Davidson
wrote:
I don't understand how it could be fine. As code grows it would
lead to people not adding useful members like history just
because of the huge repercussions.
struct User {
immutable(Foo) foos;
}
How can I as a user
On Wednesday, 16 October 2013 at 19:01:59 UTC, H. S. Teoh wrote:
On Wed, Oct 16, 2013 at 08:49:51PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 17:55:14 UTC, H. S. Teoh
wrote:
On Wed, Oct 16, 2013 at 07:23:24PM +0200, Daniel Davidson
wrote:
[...]
If you have a type that has
On Wed, Oct 16, 2013 at 09:06:05PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 18:52:23 UTC, qznc wrote:
[...]
Library code:
struct Foo { int x; }
User code:
Foo f;
immutable f2 = f;
This works, even though the library writer might not have
anticipated that
On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
On Wednesday, 16 October 2013 at 19:06:06 UTC, Daniel Davidson
wrote:
I don't understand how it could be fine. As code grows it
would lead to people not adding useful members like history
just because of the huge repercussions.
On Wed, Oct 16, 2013 at 09:45:09PM +0200, Daniel Davidson wrote:
On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
[...]
I think any usage of immutable with types/entities not initially
designed for immutability is an potential mistake and in that
sense it is good that change has
On Wednesday, 9 October 2013 at 23:05:27 UTC, qznc wrote:
On Wednesday, 9 October 2013 at 15:50:55 UTC, Daniel Davidson
wrote:
void foo(const(MutableType) mt);
void foo(immutable(MutableType) mt);
Naturally the inclination is to choose the second as it is a
stronger guarantee that no threads
On 10/10/13 1:05 , qznc wrote:
Very interesting discussion!
contract between caller and callee. If an argument is const, it means
the callee says he can handle others changing the state concurrently.
i think what the usual understanding of const for an argument to callee
is, what is written
On Wednesday, 9 October 2013 at 04:31:55 UTC, Ali Çehreli wrote:
On 10/08/2013 03:12 PM, qznc wrote:
On Monday, 7 October 2013 at 17:57:11 UTC, Ali Çehreli wrote:
To look at just one usage example, the following line
carries two
requirements:
auto a = T();
immutable b = a;
1) b
On Thursday, 10 October 2013 at 18:39:32 UTC, Christian Köstlin
wrote:
On 10/10/13 1:05 , qznc wrote:
Very interesting discussion!
contract between caller and callee. If an argument is const,
it means
the callee says he can handle others changing the state
concurrently.
i think what the usual
On Thursday, 10 October 2013 at 23:06:23 UTC, qznc wrote:
Maybe the fact that D allows this implicit copy to immutable is
the problem? If one could require the use of a specific
function, this function could be overridden with working
behavior. The following code works.
Yes - the issue
On 11/10/13 01:43, Daniel Davidson wrote:
That is probably a reasonable interpretation... but I think it will only get you
pain. The fact is, regardless of your interpretation of const arguments - the
general guideline is prefer const because immutables and mutables can be passed
in.
Which
On Wednesday, 9 October 2013 at 04:41:35 UTC, Ali Çehreli wrote:
4. Data structures should not restrict themselves to be
mutable, const,
or immutable.
What is the template of a struct that can be used as such?
Providing simple values seems to be insufficient:
struct MyInt
{
int i;
On Wednesday, 9 October 2013 at 04:31:55 UTC, Ali Çehreli wrote:
On 10/08/2013 03:12 PM, qznc wrote:
On Monday, 7 October 2013 at 17:57:11 UTC, Ali Çehreli wrote:
To look at just one usage example, the following line
carries two
requirements:
auto a = T();
immutable b = a;
1) b
On Wednesday, 9 October 2013 at 04:41:35 UTC, Ali Çehreli wrote:
On 10/08/2013 03:03 PM, qznc wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
1. If a variable is never mutated, make it const, not
immutable.
2. Make the parameter reference to immutable if that is
On Wednesday, 9 October 2013 at 15:50:55 UTC, Daniel Davidson
wrote:
void foo(const(MutableType) mt);
void foo(immutable(MutableType) mt);
Naturally the inclination is to choose the second as it is a
stronger guarantee that no threads are changing the data. Cool.
But wait, the first one still
On Wednesday, 9 October 2013 at 15:50:55 UTC, Daniel Davidson
wrote:
I would rephrase the second guideline as: Never dup or idup
an argument
to make it mutable or immutable, but require the caller to do
this
(might be able to avoid it).
Agreed. But it means you agree with me that immutable
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
1. If a variable is never mutated, make it const, not immutable.
2. Make the parameter reference to immutable if that is how you
will use it anyway. It is fine to ask a favor from the caller.
...
I think guideline 1 should
On Monday, 7 October 2013 at 17:57:11 UTC, Ali Çehreli wrote:
To look at just one usage example, the following line carries
two requirements:
auto a = T();
immutable b = a;
1) b will be an immutable copy of a.
2) T will always be usable as in that fashion.
If T appears on an API, it
On 10/08/2013 03:12 PM, qznc wrote:
On Monday, 7 October 2013 at 17:57:11 UTC, Ali Çehreli wrote:
To look at just one usage example, the following line carries two
requirements:
auto a = T();
immutable b = a;
1) b will be an immutable copy of a.
2) T will always be usable as in
On 10/08/2013 03:03 PM, qznc wrote:
On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson wrote:
1. If a variable is never mutated, make it const, not immutable.
2. Make the parameter reference to immutable if that is how you will
use it anyway. It is fine to ask a favor from the
On 10/02/2013 10:07 AM, Ali Çehreli wrote:
On 10/02/2013 06:09 AM, Daniel Davidson wrote:
I'm reviewing Ali's insightful presentation from 2013 DConf. I
wonder has he or anyone else followed up on the concepts or
formalized some guidelines that could achieve consensus.
I have not
I'm reviewing Ali's insightful presentation from 2013 DConf. I
wonder has he or anyone else followed up on the concepts or
formalized some guidelines that could achieve consensus. I
definitely agree it would be helpful to have a 50 Ways To Improve
Your D. The first thing I'd like to see is a
On 10/02/2013 06:09 AM, Daniel Davidson wrote:
I'm reviewing Ali's insightful presentation from 2013 DConf. I
wonder has he or anyone else followed up on the concepts or
formalized some guidelines that could achieve consensus.
I have not followed up on those concepts.
1. If a variable is
On Wednesday, 2 October 2013 at 17:07:55 UTC, Ali Çehreli wrote:
On 10/02/2013 06:09 AM, Daniel Davidson wrote:
1. If a variable is never mutated, make it const, not
immutable.
2. Make the parameter reference to immutable if that is how
you will use
it anyway. It is fine to ask a favor from
37 matches
Mail list logo
