[Issue 19056] UDAs can be added to imports but not retrieved
https://issues.dlang.org/show_bug.cgi?id=19056 --- Comment #3 from Smaulder --- should not be an error* --
[Issue 19056] UDAs can be added to imports but not retrieved
https://issues.dlang.org/show_bug.cgi?id=19056
Smaulder changed:
What|Removed |Added
CC||smauldersa...@gmail.com
--- Comment #2 from Smaulder ---
> In my opinion, the best solution would be to make adding UDAs to aliases
> illegal and also not allow UDAs to imports as long as imports create aliases
> behind the scenes.
I disagree, this would cause a lot of breaking changes. It will make it
difficult to write code that would otherwise be simple.
Attributes are allowed to be applied to aliases even if it does nothing is for
simplicity.
enum value = 10;
struct Foo
{
@nogc:
alias bar = value; // should be an error to allow "@nogc:"
// to apply to whole scope for simplicity
}
Just as some attributes can be applied to symbols that do not do anything:
@nogc int variable; // Still allowed, doesn't do anything
--
[Issue 19057] 2.079 changelog variadic template and default arguments
https://issues.dlang.org/show_bug.cgi?id=19057 --- Comment #14 from Jonathan M Davis --- The current behavior works well with default arguments, because then they never get accidentally matched, whereas IFTI is allowed to match arguments against them, then it becomes trivial to match them accidentally, and if that were the case, I'd argue strongly that putting default arguments on parameters that come after variadic parameters was too error-prone for it to make any sense. At least in the case where there are no default arguments, you always have to provide the arguments, so it's expected. But once you have default arguments, those arguments are no longer expected, and it becomes trivial to think that you're passing an argument that matches the variadic parameters but ends up matching at least one of the parameters after the variadic parameters. The behavior would be fatal for any attempt at something like logging because of how much would accidentally match against __FILE__, but any case where you have parameters with default arguments following varidiac parameters would be very error-prone unless the types involved were extremely unlikely to be passed to the function. I fail to see why having the parameters with default arguments matching with IFTI would ever be desirable. It's just too error-prone. --
[Issue 19070] New: Invalid octal literals `01` through `07` allowed
https://issues.dlang.org/show_bug.cgi?id=19070
Issue ID: 19070
Summary: Invalid octal literals `01` through `07` allowed
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: trivial
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kub...@gmail.com
I found these pathlogical examples pass the lexer:
---
void main()
{
assert(01 == 1); // can compile and run.
assert(010 == 8); // Error: octal literals 010 are no longer supported,
use std.conv.octal!10 instead
}
---
--
[Issue 19059] Invalid integer literal 08 and 09 allowed
https://issues.dlang.org/show_bug.cgi?id=19059 --- Comment #7 from Hiroki Noda --- I created another issue for invalid octal literals `01` through `07`. https://issues.dlang.org/show_bug.cgi?id=19070 --
[Issue 14854] @disable this inconsistent between structs and classes
https://issues.dlang.org/show_bug.cgi?id=14854
--- Comment #2 from Jonathan M Davis ---
My suggestion is to make it an error when @disable is used on a function with a
body - just like happens right now when you do it with @disable this() {} on a
struct. I can't think of any reason why this would be a problem. Certainly, I
don't see why it would ever make sense to declare an @disabled function with a
body. By definition, it's unreachable.
However, it will need to be done as a deprecation first in case anyone does
have code that has @disable on a function with a body (like in the example here
with a class).
--
[Issue 19050] Running the DMD test suite with a compiler compiled in debug mode fails due to invalid characters, -
https://issues.dlang.org/show_bug.cgi?id=19050 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9d0862343a5ceea2e63be12a29b8a525428f093b Fix Issue 19050 - Fix invalid characters in mangling Running the DMD test suite with a compiler compiled in debug mode fails due to invalid characters, `-`, exist in the mangled names of some unittest blocks. This fix centralizes the validation of mangled characters and properly replaces `-` in the mangled names of unittest blocks with `_`. --
[Issue 19050] Running the DMD test suite with a compiler compiled in debug mode fails due to invalid characters, -
https://issues.dlang.org/show_bug.cgi?id=19050 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14854] @disable this inconsistent between structs and classes
https://issues.dlang.org/show_bug.cgi?id=14854 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #1 from Tiberiu Lepadatu --- Hello! So the solution that you suggest is to make the compiler give an error when the @disabled is used? If so, do you think that this will impact some code somewhere else? I think that I will be able to write a fix for this. --
