[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #3 from nfx...@gmail.com 2011-01-02 05:45:57 PST --- (In reply to comment #2) It is not a dangerous corner case, it is a deliberate design choice. It is meant to facilitate writing generic code so that the same code can be generated for void and non-void return values. Wow, D is really full of idiocy, isn't it? If you wanted to facilitate that, you'd just allow declaring void variables and all that. I've written generic code where _that_ would have been quite useful. But returning non-void values in void functions? Garbage language feature. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5400] New: Socket.select / FD_ISSET broken on phobos/D2
http://d.puremagic.com/issues/show_bug.cgi?id=5400
Summary: Socket.select / FD_ISSET broken on phobos/D2
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: blocker
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: eric.estieven...@free.fr
--- Comment #0 from �ric Esti�venart eric.estieven...@free.fr 2011-01-02
05:51:46 PST ---
Since druntime/import/core/sys/posix/sys/select.di defines wrongly FD_ISSET as:
extern (D) bool FD_ISSET(int fd, fd_set* fdset)
{
return (fdset.fds_bits[__FDELT(fd)] __FDMASK(fd)) == 0;
}
instead of
return (fdset.fds_bits[__FDELT(fd)] __FDMASK(fd)) != 0;
= Socket.select does not work at all.
BTW, should be const:
bool FD_ISSET(int fd, const(fd_set)* fdset)
so constness could be propagated on SocketSet...
BTW (bis) select() should be in a separate module...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #4 from Iain Buclaw ibuc...@ubuntu.com 2011-01-02 06:24:38 PST --- (In reply to comment #2) It is not a dangerous corner case, it is a deliberate design choice. It is meant to facilitate writing generic code so that the same code can be generated for void and non-void return values. Just for clarification, so you allow this, but the return value is always ignored? (ie: 0) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Priority|P2 |P5 Status|RESOLVED|REOPENED CC||and...@metalanguage.com Resolution|INVALID | Severity|enhancement |major --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2011-01-02 06:48:17 PST --- This is a very problematic misfeature that takes no effort to remove. In particular I confirm it is of no or negative use to generic programming. Walter, please let's remove it in the next release. Thank you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399
--- Comment #6 from nfx...@gmail.com 2011-01-02 07:46:29 PST ---
I think the issue is with allowing stuff like this:
Result wrapCall(alias call, Result, Args...)(Args args) {
return call(args);
}
And then making it work even if the result of the call is void:
wrapCall(something, void, int, int)(1, 2);
That requires that you can return a void value. Returning a void normally
wouldn't make sense, but as you can see it simplifies generic programming.
Somehow it made sense in Walter's head to allow returning _anything_ from a
void function. (It would make sense if void would work like Scala's Unit, but
void doesn't.)
Walter, please explain.
By the way if D were really orthogonal and would follow any logic, you wouldn't
have any problem with this code:
Result wrapCall(alias call, Result, Args...)(Args args) {
try {
return call(args);
} catch {
writefln(call failed!);
return Result.init;
}
}
This works, except when Result is void. Then you have to use static if,
duplicate the core code around the actual call if that is more complicated than
in the given example, and so on. (I had this in real world code.)
Sure makes a lot of sense.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5399] Return the result of a nonvoid function in a void function
http://d.puremagic.com/issues/show_bug.cgi?id=5399
--- Comment #7 from Andrei Alexandrescu and...@metalanguage.com 2011-01-02
09:05:29 PST ---
(In reply to comment #6)
I think the issue is with allowing stuff like this:
Result wrapCall(alias call, Result, Args...)(Args args) {
return call(args);
}
And then making it work even if the result of the call is void:
wrapCall(something, void, int, int)(1, 2);
That requires that you can return a void value. Returning a void normally
wouldn't make sense, but as you can see it simplifies generic programming.
Yes, that's a classic in C++ too. My assessment refers not to forwarding across
void function, but to void functions returning non-void expressions.
To clarify: forwarding from one void function to another void function is
useful. Having a void function return a non-void value should be removed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5400] Add const to FD_ISSET
http://d.puremagic.com/issues/show_bug.cgi?id=5400 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||FIXED Summary|Socket.select / FD_ISSET|Add const to FD_ISSET |broken on phobos/D2 | --- Comment #1 from Brad Roberts bra...@puremagic.com 2011-01-02 10:43:03 PST --- The ISSET bug was addressed in bug 5209 which has already been fixed for the next release. I went ahead and added the const-ness to the isset set parameter. druntime r471 -- For the rest, you'll need to provide more details. Since this report seems to be two different parts, I'm going to mark it resolved due to the first part. Please re-file the second half as a separate report with enough specificity to allow someone to reproduce the problem. IE, include code that compiles and shows the bug. Thanks, Brad -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2810] Bogus forward reference error with auto function
http://d.puremagic.com/issues/show_bug.cgi?id=2810
Witold Baryluk bary...@smp.if.uj.edu.pl changed:
What|Removed |Added
CC||bary...@smp.if.uj.edu.pl
--- Comment #9 from Witold Baryluk bary...@smp.if.uj.edu.pl 2011-01-02
12:46:04 PST ---
Hi,
I also have similar problem, but involving two modules. Minimal test case (it
also appears when functions are templates, or returns templated classes, or int
type is changed to other type):
/*/
module m2;
auto f(int x) {
return x;
}
auto g(int x) {
return f(x);
}
/*/
/*/
module m1;
import m2 : g;
void main() {
g(5);
}
/*/
It currently depend on the order of files given to the compiler.
# dmd2 m1.d m2.d # error
m1.d(6): Error: forward reference to g
# dmd2 m2.d m1.d # works!
#
# dmd2 -c m1.d # error
m1.d(6): Error: forward reference to g
# dmd2 -c m2.d # works
#
As one can see there is actually NO forward references here. So I think it is
simpler than co-recursive version of Steven. Bug disappears when function f and
g, are moved to module m1. Or when function g have explicit return type.
It maybe also related to the bug involving order of files on command line to
the compiler.
Thanks.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 190] Cannot forward reference typedef/alias in default value for function parameter
http://d.puremagic.com/issues/show_bug.cgi?id=190 --- Comment #8 from Brad Roberts bra...@puremagic.com 2011-01-02 19:43:03 PST --- Created an attachment (id=858) Updated patch Incorporates the fixes from bug 4753 for the regression from the previous version of the patch. Tested against the code in bugs 190, 4573, and all the unit tests for dmd, druntime, and phobos. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5401] New: std.socket updates and boost license
http://d.puremagic.com/issues/show_bug.cgi?id=5401 Summary: std.socket updates and boost license Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: ch...@dprogramming.com --- Comment #0 from Chris Miller ch...@dprogramming.com 2011-01-02 22:59:59 PST --- The following changes have been made to std.socket: - License changed to Boost Software License - Version 1.0 - public constructor added for Socket that accepts an existing socket_t and its AddressFamily. - createAddress protected method added to Socket, returns a new Address object for the current address family; can be overridden to support other addresses. - Address class methods name and nameLen are now public. - Remove std.traits Select!, use ptrdiff_t instead. - Updated unittests; they were marked as broken and acted in various ways, but really they depend on the environment and network. These changes were inspired by this thread: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=115983 Also updated htmlget.d sample to compile with the latest D2. Thanks to those who have made various changes and fixes to std.socket since my last contribution. The code can be found at the following URL (due to bugzilla's original material agreement). http://www.dprogramming.com/socket14.zip -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
