View mode: basic / threaded / horizontal-split · Log in · Help
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 13/05/2012 20:42, Walter Bright wrote:
<snip>
> I'd like to see std.stream dumped. I don't see any reason for it to exist that std.stdio
> doesn't do (or should do).

So std.stdio.File is the replacement for the std.stream stuff?

How does/will it provide all the different kinds of stream that std.stream provides, as 
well as the other kinds of stream that applications will need?

What's the plan for std.cstream?

> The only reason it's there at the moment is for backwards compatibility.

So the plan is to deprecate that, then remove it, _then_ fix this issue?

Or make toString and toHash in the stream classes bypass constancy?

Stewart.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 14.05.2012 0:48, Stewart Gordon wrote:
> On 13/05/2012 20:42, Walter Bright wrote:
> <snip>
>> I'd like to see std.stream dumped. I don't see any reason for it to
>> exist that std.stdio
>> doesn't do (or should do).
>
> So std.stdio.File is the replacement for the std.stream stuff?
>
> How does/will it provide all the different kinds of stream that
> std.stream provides, as well as the other kinds of stream that
> applications will need?
>

I think I've seen proper replacement (or rather a draft of it). If only 
Steven can be bothered to finish it :)

> What's the plan for std.cstream?
>
>> The only reason it's there at the moment is for backwards compatibility.
>
> So the plan is to deprecate that, then remove it, _then_ fix this issue?
>
> Or make toString and toHash in the stream classes bypass constancy?
>
> Stewart.


-- 
Dmitry Olshansky
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On Sunday, May 13, 2012 17:39:44 Stewart Gordon wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1824
> 
> This has gone on for too long.
> 
> Object.toString, .toHash, .opCmp and .opEquals should all be const.  (It's
> also been stated somewhere that they should be pure and nothrow, or
> something like that, but I forget where.)
> 
> This makes it a nightmare to use const objects in data structures, among
> other things, at best forcing the use of ugly workarounds.  There are
> probably other, more serious effects of this that can't easily be worked
> around.
> 
> It seems that the main obstacle is rewriting the relevant methods in
> std.stream.  The current implementation doesn't make sense anyway - reading
> the entire contents of a file is certainly not the way to generate a hash
> or string representation of the stream.  I'm thinking the hash should
> probably be the stream handle, and the string representation could perhaps
> be the full pathname of the file.  Of course, what it should be for
> non-file streams is another matter.  (This would be a change at the API
> level, but when the API's as fundamentally flawed as this....)
> 
> Are there any other bits of druntime/Phobos that need to be sorted out
> before these methods can be declared const/pure/nothrow once and for all?
> 
> Stewart.

toHash, opCmp, opEquals, and toString will _all_ be required to be const @safe 
pure nothrow. Some work has been done towards that, but it hasn't been 
completed. One of the major obstacles is the inability for stuff such as 
format, to!string, or Appender to be pure right now. A number of druntime 
functions are going to need to be marked as pure for that to happen 
(particilurly reserve and capacity, but there are probably others). Some effort 
has been put in that area recently, but it hasn't been completed.

- Jonathan M Davis
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 5/13/2012 12:57 PM, Era Scarecrow wrote:
> On Sunday, 13 May 2012 at 19:43:19 UTC, Walter Bright wrote:
>> On 5/13/2012 9:39 AM, Stewart Gordon wrote:
>>> It seems that the main obstacle is rewriting the relevant methods in
>>> std.stream. The current implementation doesn't make sense anyway - reading
>>> the entire contents of a file is certainly not the way to generate a hash or
>>> string representation of the stream. I'm thinking the hash should probably be
>>> the stream handle, and the string representation could perhaps be the full
>>> pathname of the file. Of course, what it should be for non-file streams is
>>> another matter. (This would be a change at the API level, but when the API's
>>> as fundamentally flawed as this....)
>>
>> I'd like to see std.stream dumped. I don't see any reason for it to exist that
>> std.stdio doesn't do (or should do).
>>
>> The only reason it's there at the moment is for backwards compatibility.
>
> Recently in my own code I've started making use of std.stream, mostly creating
> temporary string streams to test IO in functions that would otherwise need
> actual files for unittests.

I suggest switching over to a range interface. Then, your code need not care if 
it is getting input from files, arrays, or any containers. Same for output. That 
means you can use arrays to unittest it, or write your own mock input/output ranges.


> Glancing over std.stdio, I only see specific file access functions and routines.
> If I'm doing the wrong approach please correct me now.

std.stdio's support for ranges needs some improvement.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 5/13/2012 1:48 PM, Stewart Gordon wrote:
> On 13/05/2012 20:42, Walter Bright wrote:
> <snip>
>> I'd like to see std.stream dumped. I don't see any reason for it to exist that
>> std.stdio
>> doesn't do (or should do).
>
> So std.stdio.File is the replacement for the std.stream stuff?

Not exactly. Ranges are the replacement. std.stdio.File is merely a range that 
deals with files.


> How does/will it provide all the different kinds of stream that std.stream
> provides, as well as the other kinds of stream that applications will need?

The future is a range interface, not a stream one.


> What's the plan for std.cstream?

I don't see a purpose for std.cstream.


>> The only reason it's there at the moment is for backwards compatibility.
>
> So the plan is to deprecate that, then remove it, _then_ fix this issue?
>
> Or make toString and toHash in the stream classes bypass constancy?

What do you suggest?
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On 05/13/2012 06:39 PM, Stewart Gordon wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1824
>
> This has gone on for too long.
>
> Object.toString, .toHash, .opCmp and .opEquals should all be const.

No, please.

Transitive enforced const + OO -> epic fail. (especially for unshared 
data, which is the default and most common)

The lack of head-mutable class references does not make this any better.

I'd rather keep the current state of affairs than blindly mark the 
existing methods const. Caching/lazy evaluation is everywhere. One 
single lazily cached class member implies that all of the relevant 
methods cannot use that member. What if they have to? They certainly 
have to!

Const/immutable are great for simple value-types. Classes can contain 
immutable values as fields.

> (It's also been stated somewhere that they should be pure and nothrow,
> or something like that, but I forget where.)
>

Similar concerns apply for them (but less so than for const). I don't 
want to have to violate the type system to get basic stuff done in 
OO-ish style! Forced const invariants are annoying enough already.

> This makes it a nightmare to use const objects in data structures,

Why on earth would you want to do that?

> among other things, at best forcing the use of ugly workarounds. There are
> probably other, more serious effects of this that can't easily be worked
> around.
>

I wouldn't bet on that. Marking the methods const, on the other hand, 
certainly would have serious effects.

> It seems that the main obstacle is rewriting the relevant methods in
> std.stream. The current implementation doesn't make sense anyway -
> reading the entire contents of a file is certainly not the way to
> generate a hash or string representation of the stream. I'm thinking the
> hash should probably be the stream handle, and the string representation
> could perhaps be the full pathname of the file. Of course, what it
> should be for non-file streams is another matter. (This would be a
> change at the API level, but when the API's as fundamentally flawed as
> this....)
>
> Are there any other bits of druntime/Phobos that need to be sorted out
> before these methods can be declared const/pure/nothrow once and for all?
>

Almost _all_ of Phobos would have to become const "correct", and it 
cannot, because 'const' is an over-approximation and there is no 
const-inference. const on the top-class interface invades _everything_.

Marking the methods const would break every non-trivial D program out 
there and put programmers in a frustrating straitjacket.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On Sunday, 13 May 2012 at 20:55:13 UTC, Jonathan M Davis wrote:
> toHash, opCmp, opEquals, and toString will _all_ be required to 
> be const @safe pure nothrow.

And what am I to do if my toString() method cannot be const?
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On Monday, May 14, 2012 00:30:09 Timon Gehr wrote:
> On 05/13/2012 06:39 PM, Stewart Gordon wrote:
> > http://d.puremagic.com/issues/show_bug.cgi?id=1824
> > 
> > This has gone on for too long.
> > 
> > Object.toString, .toHash, .opCmp and .opEquals should all be const.
> 
> No, please.
> 
> Transitive enforced const + OO -> epic fail. (especially for unshared
> data, which is the default and most common)
> 
> The lack of head-mutable class references does not make this any better.
> 
> I'd rather keep the current state of affairs than blindly mark the
> existing methods const. Caching/lazy evaluation is everywhere. One
> single lazily cached class member implies that all of the relevant
> methods cannot use that member. What if they have to? They certainly
> have to!
> 
> Const/immutable are great for simple value-types. Classes can contain
> immutable values as fields.

Walter fully intends to require that opEquals, opCmp, toHash, and toString all 
be const @safe pure nothrow - on both classes and structs. And the reality of 
the matter is, if that requirement _isn't_ there on classes, then the usage of 
any of those functions in @safe, const, pure, or nothrow code is seriously 
hampered - especially const and pure. This has been discussed quite a bit 
before, and we're pretty much stuck thanks to transivity. Caching and lazy 
evaluation _will_ be impossible in those functions without breaking the type 
system. Anything that absolutely requires them will probably have to either 
have to break the type system or use _other_ functions with the same 
functionality but without those attributes. In some cases though, providing 
overloads which aren't const, pure, etc. should work though.

If you want it to be otherwise, you're going to have to convince Walter, and I 
think that it's pretty clear that this is the way that it's going to have to 
be thanks to how const et al. work.

- Jonathan M Davis
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On Sunday, 13 May 2012 at 22:51:05 UTC, Jonathan M Davis wrote:
> Anything that absolutely requires them will probably have to 
> either have to break the type system or use _other_ functions 
> with the same functionality but without those attributes. In 
> some cases though, providing overloads which aren't const, 
> pure, etc. should work though.
> If you want it to be otherwise, you're going to have to 
> convince Walter, and I think that it's pretty clear that this 
> is the way that it's going to have to be thanks to how const et 
> al. work.

This is *exactly* the sort of problem I was referring to in my 
const(rant) thread, so to speak.

These const-related issues make D, simply speaking, *HARD TO USE*.
(Yes, that means even harder then C++ in some cases.)

When people say it's painful to find workarounds to problems in 
D, I hope -- at the very least -- no one will be surprised as to 
why.
May 13, 2012
Re: Getting the const-correctness of Object sorted once and for all
On Sun, May 13, 2012 at 12:42:32PM -0700, Walter Bright wrote:
[...]
> I'd like to see std.stream dumped. I don't see any reason for it to
> exist that std.stdio doesn't do (or should do).
> 
> The only reason it's there at the moment is for backwards
> compatibility.

+1. I'd love to see std.io done in the near future.


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee
1 2 3 4 5 6
Top | Discussion index | About this forum | D home