[Issue 24010] Destructor called before end of scope for tuples
https://issues.dlang.org/show_bug.cgi?id=24010 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @BorisCarvajal created dlang/dmd pull request #15351 "Fix Issue 24010 - Destructor called before end of scope for tuples" fixing this issue: - Fix Issue 24010 - Destructor called before end of scope for tuples https://github.com/dlang/dmd/pull/15351 --
[Issue 24010] Destructor called before end of scope for tuples
https://issues.dlang.org/show_bug.cgi?id=24010 Boris Carvajal changed: What|Removed |Added CC||jappleg...@gmail.com --- Comment #3 from Boris Carvajal --- *** Issue 17128 has been marked as a duplicate of this issue. *** --
[Issue 17128] Wrong destructor call, if variables declared using tuple of types.
https://issues.dlang.org/show_bug.cgi?id=17128 Boris Carvajal changed: What|Removed |Added Status|NEW |RESOLVED CC||boris...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Boris Carvajal --- *** This issue has been marked as a duplicate of issue 24010 *** --
[Issue 20135] Tuple assignment incorrectly calls destructor on freshly postblitted structs
https://issues.dlang.org/show_bug.cgi?id=20135 Boris Carvajal changed: What|Removed |Added Status|NEW |RESOLVED CC||boris...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Boris Carvajal --- *** This issue has been marked as a duplicate of issue 24010 *** --
[Issue 24010] Destructor called before end of scope for tuples
https://issues.dlang.org/show_bug.cgi?id=24010 Boris Carvajal changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #4 from Boris Carvajal --- *** Issue 20135 has been marked as a duplicate of this issue. *** --
[Issue 24016] New: ImportC: __attribute__ in switch statements: error: found `__attribute__` instead of statement
https://issues.dlang.org/show_bug.cgi?id=24016
Issue ID: 24016
Summary: ImportC: __attribute__ in switch statements: error:
found `__attribute__` instead of statement
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: jlourenco5...@gmail.com
```c
void fun(int i)
{
switch (i)
{
case 0: i++; __attribute__((fallthrough));
default: return;
}
}
```
--
[Issue 11455] Overriding template methods should raise a compile error
https://issues.dlang.org/show_bug.cgi?id=11455 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @ntrel created dlang/dmd pull request #15350 "Fix Issue 11455 - Overriding template methods should raise a compile …" fixing this issue: - Fix Issue 11455 - Overriding template methods should raise a compile error https://github.com/dlang/dmd/pull/15350 --
[Issue 24015] New: C#-style indented delimited strings
https://issues.dlang.org/show_bug.cgi?id=24015
Issue ID: 24015
Summary: C#-style indented delimited strings
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
https://dlang.org/spec/lex.html#delimited_strings allows identifier-delimited
strings like
```
q"EOS
This
is a multi-line
heredoc string
EOS"
```
However, that “The closing identifier must be placed on its own line at the
leftmost column” is annoying and ugly in code w.r.t. indentation. For example:
```d
void f()
{
string str = q"EOS
This
is a multi-line
heredoc string
EOS";
}
```
C# has triple-quote strings that are similar to D’s identifier-delimited
strings as if `""` were the identifier, however, C# allows the string to be in
one line and if it is not, the whitespace between the last newline and the
closing """ is not considered part of the string – and, of course, must be
present at the beginning of every line of the string.
For the sake of readability, D should have something similar: If the sequence
`q"` *end-of-string-identifier* *newline* is followed by whitespace (a sequence
of whitespace characters), the whitespace is repeated on every line up until a
line consists of the whitespace and the *end-of-string-identifier* `"` string
terminator, that is considered a string literal. The line-initial whitespace is
not part of the literal.
E.g.:
```d
void f()
{
string str = q"EOS
This
is a multi-line
heredoc string
EOS";
assert(str == "This\nis a multi-line\nheredoc string\n");
}
```
Theoretically, this is a breaking change, but it will be very unlikely that the
string termination sequence will be anywhere in the string, let alone after
whitespace that is repeated on every line before.
Alternatively, D can go “full C#” and just implement `"""` delimited strings
with the exact same semantics as C#:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/raw-string
--
[Issue 24014] UDAs are lost during IFTI when function pointers are involved
https://issues.dlang.org/show_bug.cgi?id=24014 Dennis changed: What|Removed |Added CC||dkor...@live.nl --- Comment #1 from Dennis --- It works with structs because structs have a unique type from which you can retrieve UDAs, but functions don't. Including UDAs in function types affects a lot for the worse: - type mangling (gets longer, more complex) - rules regarding covariance/implicit conversion, overloading, overriding - template instance re-use I think you should use `alias` parameters instead. You say it doesn't work in some cases, but if in those cases it could actually be made to work, perhaps file an enhancement request for that instead? --
[Issue 24000] show the open bracket "{" location for Error: matching `}` expected, not `End of File`
https://issues.dlang.org/show_bug.cgi?id=24000
Dlang Bot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Dlang Bot ---
dlang/dmd pull request #15334 "Fix Issue 24000 - show open bracket "{" location
for Error: matching …" was merged into master:
- 769311e2b7e5bedc77a8ca2d5fe7fd39ab65c7b8 by Nick Treleaven:
Fix Issue 24000 - show open bracket "{" location for Error: matching `}`
expected
https://github.com/dlang/dmd/pull/15334
--
[Issue 22940] Underscore disallowed after decimal separator in floating point literals
https://issues.dlang.org/show_bug.cgi?id=22940 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dlang.org pull request #3642 " [spec/lex] Improve floating point docs" was merged into master: - b1de8c3a4b46a908badbb4cb9914e27ff41dd04c by Nick Treleaven: Fix Issue 22940 - Underscore disallowed after decimal separator in floating point literals https://github.com/dlang/dlang.org/pull/3642 --
[Issue 24014] New: UDAs are lost during IFTI when function pointers are involved
https://issues.dlang.org/show_bug.cgi?id=24014
Issue ID: 24014
Summary: UDAs are lost during IFTI when function pointers are
involved
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
-
// attribute
struct Struct { string name; }
// try to retrieve attributes here
void test(T)(T t) {
pragma(msg, __traits(getAttributes, T));
}
@Struct("foo") void foo() { }
void main() {
test(); // FAIL: tuple()
}
-
It seems that when function pointers are involved the UDAs get lost during
IFTI.
For regular structure pointers it is possible to capture UDAs even during IFTI.
Here's an example:
-
import std.meta;
// attribute
struct Struct { string name; }
// try to retrieve attributes here
void test(T)(T t) {
static if (is(T X : E*, E)) {
pragma(msg, __traits(getAttributes, E)); // ok
}
}
@Struct("foo") struct Mine { }
void main() {
Mine mine;
test(); // ok: tuple(Struct("foo"))
}
-
However the same is not possible with function pointers:
-
import std.meta;
// attribute
struct Struct { string name; }
// try to retrieve attributes here
void test(X)(X t) {
static if (is(X: E*, E)) {
pragma(msg, __traits(getAttributes, E));
}
}
@Struct("foo") void foo() { }
void main() {
test(); // FAIL: tuple()
}
-
The only alternative is to pass these functions as `alias` parameters. But that
can only work with functions in some cases, and won't work with delegates.
--
[Issue 24013] [REG 2.103.0] address of a __traits(getOverloads) item is not converted to a delegate anymore
https://issues.dlang.org/show_bug.cgi?id=24013 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15347 "Fix Issue 24013 - [REG 2.103.0] address of a __traits(getOverloads) item is not converted to a delegate anymore" fixing this issue: - Fix Issue 24013 - [REG 2.103.0] address of a __traits(getOverloads) item is not converted to a delegate anymore https://github.com/dlang/dmd/pull/15347 --
[Issue 24013] [REG 2.103.0] address of a __traits(getOverloads) item is not converted to a delegate anymore
https://issues.dlang.org/show_bug.cgi?id=24013
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #4 from RazvanN ---
Reduced test case:
```
struct PropDescriptor(T)
{
void define(T delegate() aGetter, string aName) {}
}
enum Get;
mixin template PropertyPublisherImpl()
{
void collectPublicationsFromPairs(T)()
{
foreach (member; __traits(derivedMembers, T))
foreach (overload; __traits(getOverloads, T, member))
{
alias Attributes = __traits(getAttributes, overload);
static if (Attributes.length != 0)
{
auto descriptor = new PropDescriptor!ulong;
auto dg =
descriptor.define(dg, member);
}
}
}
}
void main()
{
class Bar
{
size_t _field;
mixin PropertyPublisherImpl;
this()
{
collectPublicationsFromPairs!Bar;
}
@Get size_t field()
{
return _field;
}
}
}
```
--
[Issue 24010] Destructor called before end of scope for tuples
https://issues.dlang.org/show_bug.cgi?id=24010 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- You're right. I'll look into why this is happening. --
[Issue 23941] [DIP1000] Overloading by scope should be allowed
https://issues.dlang.org/show_bug.cgi?id=23941 --- Comment #8 from Vladimir Panteleev --- Is there a better solution to the "function which only sometimes needs to make a copy" problem? --
