fix Issue 12368 - std.file.write conflicts with std.stdio.write by CyberShadow · Pull Request #2011 · dlang/phobos

CyberShadow · 2014-03-15T06:02:06Z

https://d.puremagic.com/issues/show_bug.cgi?id=12368

yebblies · 2014-03-15T06:30:06Z

Good luck. http://forum.dlang.org/post/kp1bld$1mu6$1@digitalmars.com

monarchdodra · 2014-03-15T08:58:39Z

Good luck.

Yeah, I think that's by design...

andralex · 2014-03-15T15:38:18Z

Yah, it doesn't seem this is needed. At some point or another, libraries (including stdlib) and applications will expose the same name from different modules. It doesn't seem that adding aliases like this would scale well.

yebblies · 2014-03-15T15:59:28Z

@andralex Shouldn't we try and prevent these conflicts at least within phobos? The std.file.write vs std.stdio.write comes up again and again, because all of my modules import std.stdio.

I love that the module system lets us disambiguate manually, but it would be better not to have to...

andralex · 2014-03-15T16:01:44Z

But this changes "call std.file.write" with "call fileWrite". Hardly progress. Also instead of using well-known qualification people need to learn a new symbol. How is this any better?

yebblies · 2014-03-15T16:15:19Z

I guess, although the old name is retained, so it's an alternative and not a replacement.

I'm more concerned about future phobos additions introducing more conflicts. encode and compress are two which seem likely.

andralex · 2014-03-15T16:22:29Z

I guess, although the old name is retained, so it's an alternative and not a replacement.

It's more churn for no progress.

I'm more concerned about future phobos additions introducing more conflicts. encode and compress are two which seem likely.

I understand. Let's cross that bridge when we get to it.

OK to close?

JakobOvrum · 2014-03-15T16:22:37Z

There have been lengthy discussions about unambiguous contextual names versus pushing the burden of disambiguating on the user. Although it's a bit of a hand-wavy argument, I think the consensus generally gravitates towards the latter approach, and that is certainly the approach exercised in Phobos today. If someone wants to change this - as I said in the bug report too - it should be taken up in dm.D, not in a small Github PR.

CyberShadow · 2014-03-15T17:53:13Z

After posting this, I realized that this was not, in fact, the change that I wanted.

The problem with disambiguating conflicts using the fully-qualified module name is that it doesn't work with UFCS chaining. However, the write signature isn't very UFCS-friendly to begin with, because you're most likely to be chaining the data to write to the file, and not the filename. So I what I really wanted was a writeTo function with the arguments swapped. I don't know if that passes the trivia test, though, but it does solve two tiny annoyances in one go.

Anyway, I'd like to reply to two arguments posted here:

If someone wants to change this - as I said in the bug report too - it should be taken up in dm.D, not in a small Github PR.

I sort of disagree here, because discussions on the NG come and go, lots of things and proposals and arguments are presented and ultimately no one comes up with something concrete and the discussion stalls and nothing gets done. A GitHub PR presents a concrete change that can be reviewed on its own merits.

Second, Jakob brought up the renamed import argument. I'm not sure I like the idea of renamed imports in general, because these are only a little better than pasting a bunch of custom helper functions at the top of each module. In effect, you are creating your very own tiny adapter library, with new symbols that map to symbols in the standard library, which everyone reading your code needs to know. They won't be encapsulated properly and they will likley be different from one programmer to another. These module-local "customizations" bother me more than the other proposed solutions, personally.

OK to close?

Do we want a writeTo? If not, OK to close.

andralex · 2014-03-15T19:44:30Z

I think there's merit in toFile that takes buffer first and file second.

andralex · 2014-03-15T19:45:12Z

How about we make that change, document it nicely and with examples, all in this pull request.

JakobOvrum · 2014-03-15T19:46:36Z

How about we make that change, document it nicely and with examples, all in this pull request.

Agreed, toFile can justify itself with a nice UFCS example. It should then be obvious to the reader which of them is used for what (write and toFile should probably reference each other with See_Also as well).

CyberShadow · 2014-03-16T00:01:25Z

Hmm. I've been thinking.

A toFile function would be more useful if it would accept a range, rather than only an array. This way, one wouldn't need to buffer all the data of a range into memory just to send it to disk immediately after.

std.stdio.File already has a range interface (LockingTextWriter), but it would not be suitable here because it does some complicated things with string types, which go against the principle of std.file.write (you wouldn't be able to use it to e.g. convert a file to UTF-32 without casting the dstring to an uint[] first).

So, there would be two overloads of toFile with different template constraints (one for arrays of POD types, such as void[] or string, and one for ranges). Question: what should the constraints for those be? Is there precedent for this in Phobos? Or am I massively overthinking this and should just leave it at arrays like std.file.write?

andralex · 2014-03-16T00:14:19Z

YES. I was thinking the exact same thing. toFile is the perfect sink!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

CyberShadow · 2014-03-16T05:58:38Z

All right, pushed first toFile implementation. I like how the example turned out, a nice showcase of std.algorithm and std.range, although it might be a bit too much for this particular function.

CyberShadow · 2014-03-16T05:59:27Z

Here is its output, BTW:

andralex · 2014-03-16T06:13:53Z

Oh, I was expecting toFile to take the file name, but taking a File is even better it seems.

CyberShadow · 2014-03-16T06:14:50Z

I added a convenience shorthand which takes a filename too, if that's OK :)

andralex · 2014-03-16T06:16:22Z

std/stdio.d

since this is on its own line the previous one should be as well

Like this?

iota(-1, 3, 2.0/size).map! ( y => iota(-1.5, 0.5, 2.0/size).map! ( x => cast(ubyte)(1+ recurrence!((a, n) => x + y*1i + a[n-1]^^2)(0+0i) .take(ubyte.max) .countUntil!(z => z.re^^2 + z.im^^2 > 4)) ) ).toFile(stdout);

It looks a bit weird...

no, the previous closing paren

Oh, you mean the next one (since this comment is attached to the first one's line). Okay.

andralex · 2014-03-16T06:17:47Z

lgtm modulo nits

andralex · 2014-03-16T06:19:03Z

I'd say no shorthand; for consistency we'd need to put it in std.file, which is odd.

andralex · 2014-03-16T06:19:22Z

r.toFile(File("name")) is good enough

CyberShadow · 2014-03-16T06:20:18Z

r.toFile(File("name"))

That'll open it for reading, not writing... and you'll almost surely want "b" so your binary data doesn't get corrupted.

CyberShadow · 2014-03-16T08:39:16Z

So, what of the shorthand? Aye or nay? It appears to be hanging by the "rb" mode string.

WalterBright · 2014-03-16T09:27:43Z

std/stdio.d

Hmm, why is this function better than:

r.copy(f);

?

File does not have a range interface, LockingTextWriter does

LockingTextWriter does some things with strings to put them in the FILE*'s orientation

Since we know it doesn't make sense to write pointers to files, we can have toFile write arrays and ranges of any number of dimensions (see the example).

File is not an output range. You have to use File.lockingTextWriter for that, which apparently deals with text.

edit:

Oops, didn't refresh.

braddr · 2014-03-16T12:28:36Z

This pull request hung on all the non-windows testers

… to a file

dlang-bot · 2016-01-13T12:29:36Z

Fix	Bugzilla	Description
✓	12379	Add toFile function which writes its first argument to a file

CyberShadow · 2016-01-13T12:29:50Z

OK, fixed up and updated.

JackStouffer · 2016-01-14T04:09:43Z

Proper/safe file writing is beyond me, so I can't really comment on the quality, but I am glad this isn't dead as it has some cool changes :)

quickfur · 2016-01-14T04:12:42Z

lockingBinaryWriter is something we ought to have had since a long time ago! (IMO :-P) So the sooner this merges, the better.

quickfur · 2016-01-14T04:14:48Z

std/stdio.d

👍 Love this code example.

andralex · 2016-03-27T04:54:54Z

std/stdio.d

+        FILE* fps_;
+
+        // the unshared version of fps
+        @property _iobuf* handle_() @trusted { return cast(_iobuf*)fps_; }


space after )

Daniel says no

andralex · 2016-03-27T05:06:50Z

Auto-merge toggled on

andralex · 2016-03-27T05:06:54Z

Auto-merge toggled off

andralex · 2016-03-27T05:07:13Z

I approve the addition with the nits mentioned. Go for it!

dlang-bot · 2016-03-27T05:43:08Z

Fix	Bugzilla	Description
✓	12379	Add toFile function which writes its first argument to a file

CyberShadow · 2016-03-27T05:43:50Z

Fixed style nits.

dlang-bot · 2016-03-27T08:41:29Z

Fix	Bugzilla	Description
✓	12379	Add toFile function which writes its first argument to a file

dlang-bot · 2016-03-27T08:52:39Z

Fix	Bugzilla	Description
✓	12379	Add toFile function which writes its first argument to a file

JakobOvrum · 2016-03-27T10:44:17Z

Auto-merge toggled on

andralex reviewed Mar 16, 2014
View reviewed changes

WalterBright reviewed Mar 16, 2014
View reviewed changes

CyberShadow added 2 commits January 13, 2016 12:29

std.stdio: Add lockingBinaryWriter

60448be

fix Issue 12379 - Add toFile function which writes its first argument…

458c1ce

… to a file

CyberShadow force-pushed the fix12368 branch from cfa3dca to 458c1ce Compare January 13, 2016 12:29

CyberShadow added Review:Needs Review and removed Merge:Blocked labels Jan 13, 2016

quickfur reviewed Jan 14, 2016
View reviewed changes

std/stdio.d

Copy link

Member

quickfur Jan 14, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Love this code example.

quickfur mentioned this pull request Jan 15, 2016

Add std.stdio.File.setRawMode(). #3929

Closed

andralex reviewed Mar 27, 2016
View reviewed changes

CyberShadow force-pushed the fix12368 branch from cafa68f to 360bccd Compare March 27, 2016 08:41

std.stdio: Fix style nits

c697f64

CyberShadow force-pushed the fix12368 branch from 360bccd to c697f64 Compare March 27, 2016 08:52

JakobOvrum merged commit 99651dc into dlang:master Mar 27, 2016

CyberShadow mentioned this pull request Apr 19, 2016

Add shift(): wrapper for front and popFront #4010

Closed

CyberShadow mentioned this pull request Aug 29, 2016

rdmd: compile the root module in the same step as getting the dependencies dlang/tools#194

Merged

Uh oh!

Conversation

CyberShadow commented Mar 15, 2014

Uh oh!

yebblies commented Mar 15, 2014

Uh oh!

monarchdodra commented Mar 15, 2014

Uh oh!

andralex commented Mar 15, 2014

Uh oh!

yebblies commented Mar 15, 2014

Uh oh!

andralex commented Mar 15, 2014

Uh oh!

yebblies commented Mar 15, 2014

Uh oh!

andralex commented Mar 15, 2014

Uh oh!

JakobOvrum commented Mar 15, 2014

Uh oh!

CyberShadow commented Mar 15, 2014

Uh oh!

andralex commented Mar 15, 2014

Uh oh!

andralex commented Mar 15, 2014

Uh oh!

JakobOvrum commented Mar 15, 2014

Uh oh!

CyberShadow commented Mar 16, 2014

Uh oh!

andralex commented Mar 16, 2014

Uh oh!

CyberShadow commented Mar 16, 2014

Uh oh!

CyberShadow commented Mar 16, 2014

Uh oh!

andralex commented Mar 16, 2014

Uh oh!

CyberShadow commented Mar 16, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andralex commented Mar 16, 2014

Uh oh!

andralex commented Mar 16, 2014

Uh oh!

andralex commented Mar 16, 2014

Uh oh!

CyberShadow commented Mar 16, 2014

Uh oh!

CyberShadow commented Mar 16, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

braddr commented Mar 16, 2014

Uh oh!

dlang-bot commented Jan 13, 2016

Uh oh!

CyberShadow commented Jan 13, 2016

Uh oh!

JackStouffer commented Jan 14, 2016

Uh oh!

quickfur commented Jan 14, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!