[Issue 12578] New: Allow local function overloading
https://issues.dlang.org/show_bug.cgi?id=12578
Issue ID: 12578
Summary: Allow local function overloading
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: monarchdo...@gmail.com
From the conversation:
http://forum.dlang.org/thread/gxzqflbxjmlewdsfw...@forum.dlang.org
Basically, this fails:
//
void main()
{
void foo();
void foo(int);
}
//
Error: declaration foo is already defined
//
I *think* this is according to spec? However, I find this behavior unrational,
since you can get it to work with a simple wrap:
//
void main()
{
static struct S
{
static void foo();
static void foo(int);
}
alias foo = S.foo;
}
//
Fine! No problem!
//
Given that the second example compiles, I think the D language should allow
local function overloading.
...
Or, if the issue is one of scope/context/forwardreferences (?) to at least
allow overloading of static local functions, eg:
//
void main()
{
static void foo();
static void foo(int);
}
//
--
[Issue 12578] Allow local function overloading
https://issues.dlang.org/show_bug.cgi?id=12578 --- Comment #1 from monarchdo...@gmail.com --- Also relevant: The declaration of nested structs/classes: https://github.com/D-Programming-Language/phobos/pull/2074/files --
[Issue 12578] Allow local function overloading
https://issues.dlang.org/show_bug.cgi?id=12578 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com --- It would also be in line with the turtles all the way down approach that we tend to favor to have nested functions be overloadable just like non-nested functions can be. The fact that nested functions can't be overloaded is inconsistent with functions in the rest of the language. --
[Issue 12573] Implicit immutable cast for ref/out argument of pure functions
https://issues.dlang.org/show_bug.cgi?id=12573
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #1 from Steven Schveighoffer schvei...@yahoo.com ---
I think it is dangerous to allow this. Allowing the implicit casting of a
return is OK, since you cannot modify the return via the mutable reference, but
allowing arbitrary assignment inside the function allows modifying the mutable
reference, breaking immutability.
If we consider the trivial case:
string foo2(in string s, ref string sout) pure nothrow
{
auto s2 = s.dup;
sout = s2; // this would potentially be allowed
auto s3 = sout.idup; // copy the data
s2[0] = 'a'; // now modified immutable data referenced by sout.
return sout.idup; // could be changed to return s3?
}
Basically, the compiler can make the legal assumption that since s3 and sout
are immutable, and have not changed, calling idup on sout will reasonably
result in the same value that s3 has. It would be a legal optimization.
However, on return, sout has changed from what s3 contains, so the return value
may not be equivalent to sout.
A return does not have this vulnerability, since the function ends at a return
statement, and the cast is effectively occurring after the return. In fact, you
have no access to the return, so it's not possible to use it in a pure manner
inside the function.
I would recommend not allowing this, unless you could make more restrictive
rules. I'm not sure if it's worth it. May be better to focus on multiple return
values.
--
[Issue 12512] .dup of const structs does not work
https://issues.dlang.org/show_bug.cgi?id=12512 --- Comment #8 from monarchdo...@gmail.com --- (In reply to Walter Bright from comment #7) (In reply to monarchdodra from comment #6) Could we then allow dup to return const(T)[] for the cases where it can't return a mutable then? I suspect that would be considered surprising behavior. I guess it depends on how you consider dup to operate. Arguably, it could just be duplicates the array. Strips the qualifiers it can, for convenience. Under such circumstance, it keeps its existing semantics, but is expanded to support more types than before. --
[Issue 12579] DMD rejects valid function literal
https://issues.dlang.org/show_bug.cgi?id=12579 brian-sch...@cox.net changed: What|Removed |Added Keywords||accepts-invalid, spec Blocks||10233 --
[Issue 12579] New: DMD rejects valid function literal
https://issues.dlang.org/show_bug.cgi?id=12579
Issue ID: 12579
Summary: DMD rejects valid function literal
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: brian-sch...@cox.net
From the grammar documentation:
Decl:
StorageClasses(opt) BasicType Declarator FunctionBody
DMD rejects the following code:
void function() foo {};
and accepts the following:
void function() foo = {};
According to the grammar spec, the latter should be parsed as a variable
declaration whose type is void function(), with a name of foo and an empty
struct initializer. (By the way, the grammar does not allow empty struct
initializers). This should not pass semantic analysis because a struct literal
is not of type void function().
--
[Issue 10233] [Tracker] Grammar issues
https://issues.dlang.org/show_bug.cgi?id=10233 brian-sch...@cox.net changed: What|Removed |Added Depends on||12579 --
[Issue 12580] New: [REG2.066a] dup() won't accept void[]
https://issues.dlang.org/show_bug.cgi?id=12580
Issue ID: 12580
Summary: [REG2.066a] dup() won't accept void[]
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: j...@red.email.ne.jp
Today I have just updated DMD from git-head.
So it won't compile the following code.
void main()
{
void[] v = [0];
auto v2 = v.dup;
}
This should be caused by the recent compiler change.
--
