www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Requiring weak purity for opAssign, postblit

reply dsimcha <dsimcha yahoo.com> writes:
I've been thinking about adding purity to various parts of Phobos and one
thing that limits this in the case of containers is templated containers,
arrays, etc. that may be instantiated with a user-defined type.  In theory,
even assigning/copying a user-defined type could be impure.  Does anyone see a
problem with requiring opAssign and postblits to be weakly pure to solve this
problem?
Dec 25 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
dsimcha:


 Does anyone see a problem with requiring opAssign and postblits to be
 weakly pure to solve this problem?


Time ago I have even suggested contracts (pre/post/invariants) to be pure (as
Design by Contract asks), or at least class invariants to be const on default.

Bye,
bearophile
Dec 25 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 dsimcha:

 Does anyone see a problem with requiring opAssign and postblits to be
 weakly pure to solve this problem?


 Time ago I have even suggested contracts (pre/post/invariants) to be pure (as


Design by Contract asks), or at least class invariants to be const on default.

 Bye,
 bearophile


Yeah, this is a good idea iff we fix the template pure issue.
Dec 25 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 December 2010 08:50:19 dsimcha wrote:

 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 

 dsimcha:

 Does anyone see a problem with requiring opAssign and postblits to be
 weakly pure to solve this problem?


 
 Time ago I have even suggested contracts (pre/post/invariants) to be pure
 (as


 
 Design by Contract asks), or at least class invariants to be const on
 default.
 

 Bye,
 bearophile


 
 Yeah, this is a good idea iff we fix the template pure issue.


You can mark them as pure already. They're just not forced to be pure.

pure invariant()
{
  //This invariant is pure.
}


What would be really nice though is a version of writeln intended only for
debug 
purposes which worked in pure functions. As I understand it, the main reason 
that invariants weren't pure in the first place was to allow for debug output, 
which can be extremely useful.

- Jonathan M Davis
Dec 25 2010
prev sibling next sibling parent reply =?UTF-8?Q?Tomek=20Sowi=C5=84ski?= <just ask.me> writes:
dsimcha <dsimcha yahoo.com> wrote:

 I've been thinking about adding purity to various parts of Phobos and
 one
 thing that limits this in the case of containers is templated
 containers,
 arrays, etc. that may be instantiated with a user-defined type.  In
 theory,
 even assigning/copying a user-defined type could be impure.  Does
 anyone see a
 problem with requiring opAssign and postblits to be weakly pure to
 solve this
 problem?


I guess a postblit could obtain a "new" instance by taking one off a
freelist.

From bird's eye, the more code I write with the new pure design the more
these two thoughts get reinforced:

1. Technically speaking it's excellent, solves quite a bit.
2. Functions ought to be weakly pure by default (please don't dismiss as
bikeshedding). It's the most common case by a large margin. Plus,
functions that do use globals need more attention from reviewers, so
making *them* greppable saves time.

-- 
Tomek
Dec 25 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Tomek Sowiński:


 2. Functions ought to be weakly pure by default (please don't dismiss as
 bikeshedding). It's the most common case by a large margin.


This is right. I'd like functions to be pure on default and use an attribute
like  outer() when whey aren't pure because they use mutables from outer scopes
(in the () of outer you optionally list all the in/out/inout mutables from the
outer scope). But probably this will not change now.

Bye,
bearophile
Dec 25 2010
prev sibling parent spir <denis.spir gmail.com> writes:
On Sat, 25 Dec 2010 18:46:17 +0000 (UTC)
Tomek Sowi=C5=84ski <just ask.me> wrote:


 dsimcha <dsimcha yahoo.com> wrote:

 I've been thinking about adding purity to various parts of Phobos and
 one
 thing that limits this in the case of containers is templated
 containers,
 arrays, etc. that may be instantiated with a user-defined type.  In
 theory,
 even assigning/copying a user-defined type could be impure.  Does
 anyone see a
 problem with requiring opAssign and postblits to be weakly pure to
 solve this
 problem?


=20
 I guess a postblit could obtain a "new" instance by taking one off a
 freelist.
=20
 From bird's eye, the more code I write with the new pure design the more
 these two thoughts get reinforced:
=20
 1. Technically speaking it's excellent, solves quite a bit.
 2. Functions ought to be weakly pure by default (please don't dismiss as
 bikeshedding). It's the most common case by a large margin. Plus,
 functions that do use globals need more attention from reviewers, so
 making *them* greppable saves time.


 sinner functions ;-)

Denis



-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Dec 25 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 25 December 2010 08:19:32 dsimcha wrote:

 I've been thinking about adding purity to various parts of Phobos and one
 thing that limits this in the case of containers is templated containers,
 arrays, etc. that may be instantiated with a user-defined type.  In theory,
 even assigning/copying a user-defined type could be impure.  Does anyone
 see a problem with requiring opAssign and postblits to be weakly pure to
 solve this problem?


This is one of those things where I want to say that it's a good idea, but I'm 
afraid that it's not. At the moment, I can think of any good reason why it
would 
_not_ be a good idea, but I've had plenty of cases in code where I would have 
expected it to be possible to have a function pure and it just didn't work. It 
probably would be quite easy if you had a version of opAssign() that took a
type 
other than the type being assigned to, but I'm not sure if we care about being 
able to do that.

What we _really_ need for templates is the ability to make them conditionally 
pure. That is, as long as all of the functions that they call are pure, they're 
pure. This wouldn't work with functions in general, but because templates could 
be checked for purity as they're being instantiated, it would be doable.
Without 
that, it's going to be _really_ hard to make a _lot_ of functions pure - 
especially in std.algorithm.

As for this particular case, I _think_ that we could enforce that opAssign()
and 
postblit be pure, but if either has to call any helper functions which can't be 
pure, then that's going to be a cause of code duplication in opAssign() and 
postblit constructors. So, it might work, but I'm not 100% sure that it's 
reasonable.

- Jonathan M Davis
Dec 25 2010