Re: File.write introduces \r regardless of presence
On Saturday, 16 July 2022 at 20:08:38 UTC, Adam D Ruppe wrote: The default here is write in text mode, change the "w" to "wb" and it won't molest your line endings any more. Thank you, that worked. This raises 3 questions for me. 1. Are there any nasty pitfalls with this change that might force me to find a workaround? (eg. en/decoding issues or the like?) 2. Does this mean readText reads in binary mode? 3. The documentation refers to `the same semantics as in the C standard library fopen function`, would this also include the "x" subspecifier in C2011? _I'm not sure having documentation depend on other documentation that may change was a good idea..._
Re: File.write introduces \r regardless of presence
On Saturday, 16 July 2022 at 19:54:08 UTC, HuskyNator wrote:
File("test.txt", "w").write(a);
The default here is write in text mode, change the "w" to "wb"
and it won't molest your line endings any more.
File.write introduces \r regardless of presence
While trying to figure out why my reading from & write back to
file kept increasing the size of my entries, I figured out
File.write always introduces a \r character before any \n
characters, even if they are already preceded by one.
Is this intentional behaviour or an oversight?
Example:
```d
module app;
import std.stdio;
import std.file;
void main(string[] args) {
string a = "`a\r\n\r\nb`\r\n";
File("test.txt", "w").write(a);
}
```
Content of text.txt:
```
`a\r\r\n\r\r\nb\`\r\r\n
```
Re: Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
On Saturday, 16 July 2022 at 12:40:09 UTC, Paul Backus wrote: On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote: On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote: On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote: [...] Yes, it should behave the way you expect. The current behavior is a bug. I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242 It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported? The interface works fine, it's just that the `InputRangeObject!R` instance itself does not satisfy `isRandomAccessRange`: ```d auto seqObj = sequence!((a, n) => n).inputRangeObject; RandomAccessInfinite!size_t seqIface = seqObj; static assert( isRandomAccessRange!(typeof(seqIface))); // interface passes static assert(!isRandomAccessRange!(typeof(seqObj))); // object fails ``` So if you code to the interfaces and ignore the concrete type of the range object, you should not have any problems. Thanks this definitely alleviates the issue somewhat. However it is definitely surprising that an object which literally derives from an interface cannot be tested to implement said interface. Is this inconsistency not a problem?
Re: Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote: On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote: On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote: First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library? Yes, it should behave the way you expect. The current behavior is a bug. I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242 It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported? The interface works fine, it's just that the `InputRangeObject!R` instance itself does not satisfy `isRandomAccessRange`: ```d auto seqObj = sequence!((a, n) => n).inputRangeObject; RandomAccessInfinite!size_t seqIface = seqObj; static assert( isRandomAccessRange!(typeof(seqIface))); // interface passes static assert(!isRandomAccessRange!(typeof(seqObj))); // object fails ``` So if you code to the interfaces and ignore the concrete type of the range object, you should not have any problems.
Re: Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote:
On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:
On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:
First, please can someone clarify if the behaviour I expect
in the last line is consistent with the intention of the
library?
Yes, it should behave the way you expect. The current behavior
is a bug.
I've submitted a report for it here:
https://issues.dlang.org/show_bug.cgi?id=23242
It looks like the resolution is that this can't be fixed? I'm
not sure I understand the conclusion. What does this mean for
this part of the library then? Should the
RandomAccessInfinite!E interface be removed since it's not
fully supported?
What if infinite-ness is a class/struct level property distinct
from empty-ness like `const enum bool infinite`? It appears to
me that this is what we try to achieve by the unfortunate
coupling of declaring `empty` as a manifest constant to denote an
infinite range. If we have a distinct convention for declaring
infiniteness then for the infinite range case we can insert `bool
empty(){return false;}` (or `const enum bool = false)`
automatically or check agreement. We can even have a mixin like
the `ImplementLength` one that can add both `infinite` and
`empty` in one go, which might be useful for implementing
infinite ranges.
Re: Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote: On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote: First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library? Yes, it should behave the way you expect. The current behavior is a bug. I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242 It looks like the resolution is that this can't be fixed? I'm not sure I understand the conclusion. What does this mean for this part of the library then? Should the RandomAccessInfinite!E interface be removed since it's not fully supported?
