[Issue 3235] New: Function literals must be deduced as function or delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3235
Summary: Function literals must be deduced as function or
delegate
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@metalanguage.com
Consider:
void foo(alias pred)() {
pragma(msg, pred.stringof);
}
unittest {
foo!((i) { return i 0; })();
int z = 1;
foo!((i) { return i z; })();
}
void main(string[] args)
{
}
This outputs:
__funcliteral1(__T2)
__dgliteral3(__T4)
because the first literal does not have to be a delegate.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as function or delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3235
--- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2009-08-08
07:17:17 PDT ---
(In reply to comment #0)
Consider:
void foo(alias pred)() {
pragma(msg, pred.stringof);
}
unittest {
foo!((i) { return i 0; })();
int z = 1;
foo!((i) { return i z; })();
}
void main(string[] args)
{
}
This outputs:
__funcliteral1(__T2)
__dgliteral3(__T4)
because the first literal does not have to be a delegate.
I meant that right now this outputs:
__dgliteral1(__T2)
__dgliteral3(__T4)
and it should output:
__funcliteral1(__T2)
__dgliteral3(__T4)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1977] Relax warnings (D1)/errors (D2) for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 --- Comment #22 from Jason House jason.james.ho...@gmail.com 2009-08-08 09:17:31 PDT --- (In reply to comment #21) I'm only worrying about D2 where implicit narrowing conversions is part of the spec. ulong%1000 should implicitly allowed when assigning to an integer. Should it be a distinct bugzilla entry? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1977] Relax warnings (D1)/errors (D2) for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #23 from Andrei Alexandrescu and...@metalanguage.com 2009-08-08 09:39:54 PDT --- (In reply to comment #22) (In reply to comment #21) I'm only worrying about D2 where implicit narrowing conversions is part of the spec. ulong%1000 should implicitly allowed when assigning to an integer. Should it be a distinct bugzilla entry? Range value propagation, which was implemented recently, should take care of this. It's among the simplest examples that should work with range value propagation. The compiler must infer that a % 1000 has range -999 through 999 and therefore should allow it to fit in a short or int. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as function or delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3235 Stewart Gordon s...@iname.com changed: What|Removed |Added Status|NEW |RESOLVED CC||s...@iname.com Resolution||INVALID --- Comment #2 from Stewart Gordon s...@iname.com 2009-08-08 11:14:14 PDT --- This is as designed. http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral If the keywords function or delegate are omitted, it defaults to being a delegate. Having the type of a function/delegate literal depend on its contents like this makes it hard for someone reading the code to tell which it is. Since function pointers and delegates are not generally interchangeable, AISI it's desirable to keep their literal notations distinct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as function or delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3235 --- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2009-08-08 11:55:19 PDT --- (In reply to comment #2) This is as designed. http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral If the keywords function or delegate are omitted, it defaults to being a delegate. Having the type of a function/delegate literal depend on its contents like this makes it hard for someone reading the code to tell which it is. Since function pointers and delegates are not generally interchangeable, AISI it's desirable to keep their literal notations distinct. I think type deduction should help here as much as anywhere else. If you do want a delegate, you can always use the delegate keyword. Plus, all algorithms in std.algorithm take an efficiency toll when used with literals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as function or delegate
http://d.puremagic.com/issues/show_bug.cgi?id=3235 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #4 from Andrei Alexandrescu and...@metalanguage.com 2009-08-08 11:57:05 PDT --- (In reply to comment #2) This is as designed. http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral If the keywords function or delegate are omitted, it defaults to being a delegate. Having the type of a function/delegate literal depend on its contents like this makes it hard for someone reading the code to tell which it is. Since function pointers and delegates are not generally interchangeable, AISI it's desirable to keep their literal notations distinct. I think type deduction should help here as much as anywhere else. If you do want a delegate, you can always use the delegate keyword. Plus, all algorithms in std.algorithm take an efficiency toll when used with literals. (Please do not mark this as resolved; I've discussed with Walter before posting it, and he suggested I do. In general, the spec of D2 is fluid enough to not be a strong reason for invalidating a bug report. Thanks.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] New: Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 Summary: Access Violation during reference counting Product: D Version: 2.032 Platform: x86 OS/Version: Windows Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bart...@relisoft.com RcName is a struct that does reference counting. When I store an instance of RcName in an object, everything seems to go fine, except that I get an access violation during the final destruction. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 --- Comment #1 from Bartosz Milewski bart...@relisoft.com 2009-08-08 12:31:46 PDT --- Created an attachment (id=439) -- (http://d.puremagic.com/issues/attachment.cgi?id=439) test case for access violatin while reference counting -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2476] std.stdio fails to compile
http://d.puremagic.com/issues/show_bug.cgi?id=2476 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||FIXED --- Comment #8 from Brad Roberts bra...@puremagic.com 2009-08-08 12:59:11 PDT --- dmd.conf was fixed to include druntime's path long ago. Marking resolved. Please reopen with a complete description of the current problem if there's anything left to do here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-08-08 13:23:38 PDT --- compile with -gc and run under windbg, the windows debugger. Shows that it crashes because _cnt is null in the first line of release(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231 --- Comment #10 from Cristi Vlasceanu crist...@zerobugs.org 2009-08-08 13:25:53 PDT --- (In reply to comment #9) (In reply to comment #5) I think that marking the bug as invalid because of a limitation in the implementation is ridiculous. AIUI this isn't a limitation in the implementation, but a characteristic of how D is designed. The fix (which I am applying to the my source tree at http://dnet.codeplex.com/) is very simple: continue the look up in enclosing scope. Better beware of hijacking vulnerabilities. This is possibly valid, do you have an example that drives your point? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 --- Comment #4 from Bartosz Milewski bart...@relisoft.com 2009-08-08 15:20:08 PDT --- I simplified the example. It turns out that the destructor of a class object Counter is called. I have no idea what mechanism may call the destructor other than GC. A new file attached. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231 --- Comment #11 from Stewart Gordon s...@iname.com 2009-08-08 16:07:09 PDT --- (In reply to comment #10) (In reply to comment #9) Better beware of hijacking vulnerabilities. This is possibly valid, do you have an example that drives your point? I'm not sure if there are any in this particular instance, but it's something to be careful of whenever you try to resolve a symbol to a different scope depending on how it's being used. It may be the case that the worst that can happen here is that the class-level function conflicts with an opCall on the module-level class. While no call of the form Bar(...) is happening here, I can see it getting confusing if one does occur -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231
--- Comment #12 from Tim M tim.matthe...@gmail.com 2009-08-08 16:42:01 PDT
---
Adding the dot is so trivial and takes no time at all. I do believe that this
is indeed a bug anyway explanation of such:
This code will not compile:
class A
{
void func();
func getFunc()
{
return null;
}
}
void main()
{
}
You cannot return a 'func' as it is not a type. 'func' is actually an instance
of 'delegate' so it should have been declared as that.
class A
{
void func();
void getFunc()
{
new func();
}
}
void main()
{
}
Here 'getFunc' is declared as void but it doesn't compile either because this
time I am trying to new a 'func' which causes a compile error again because
'func' is not a type but an instance of delegate.
Whenever a peice of D code contains 2 identifiers next to each other like so:
AB XY
It can only mean either XY is an instance (whether that be value, ref, of
function returning) and AB is a type. Likewise I can't 'new' everything either.
The bug is simply that dmdfe wasn't attempting to find a type or instance with
the particular name but it was satisfied with the first symbol it found.
If this indeed hard to fixup now (and I would rather Walter focus on more
important issues) then adding a couple of dots is something I wouldn't mind to
do either (it would require a few bytes of code)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2702] Struct initialisation silently inserts deadly casts
http://d.puremagic.com/issues/show_bug.cgi?id=2702 --- Comment #3 from Don clugd...@yahoo.com.au 2009-08-08 22:19:09 PDT --- I have confirmed that after completely removing that section of code, the DMD test suite still passes all tests. I tried to construct a valid case which required that code, but was unable to find one -- it looks as though that code is ONLY creating bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2469] ICE(cod1.c) arbitrary struct accepted as struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=2469 --- Comment #8 from Don clugd...@yahoo.com.au 2009-08-08 22:21:44 PDT --- There's a patch for the original bug in bug 2702. It's unrelated to the ICE. (It's really annoying when new bugs are reported in the comments for existing bugs, it's not clear what to do with them). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
