[Issue 21645] template value argument capriciously rejects class objects literals
https://issues.dlang.org/show_bug.cgi?id=21645 --- Comment #1 from Adam D. Ruppe --- I suspect the reason has to do with mangling the class values, but it isn't that different than a struct, so I don't think it is fundamentally problematic. Another related problem is that `enum Object o = new Object;` is not allowed, since then you'd have questions of Object aliasing at runtime (arrays are arguably similar but they solve it by reallocating for each use, so perhaps a class could do that too, but I also don't think this is required at all since a template can just use it at CTFE then export it as `static` instead of `enum`). --
[Issue 21645] New: template value argument capriciously rejects class objects literals
https://issues.dlang.org/show_bug.cgi?id=21645
Issue ID: 21645
Summary: template value argument capriciously rejects class
objects literals
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: destructiona...@gmail.com
https://dlang.org/spec/template.html#template_value_parameter
"Template value parameter types can be any type which can be statically
initialized at compile time."
So far, this ought to allow classes since they can be statically initialized at
compile time! And indeed, the compiler lets me write the parameter.
---
template test(Object o) { } // compiles fine
---
However, the spec then says:
"Template value arguments can be integer values, floating point values, nulls,
string values, array literals of template value arguments, associative array
literals of template value arguments, or struct literals of template value
arguments."
Which makes that definition useless since it is impossible to actually pass an
argument to that template!
---
void main() { test!(new Object); } // rejected!
---
There's no justification for this ever since classes were implemented in CTFE.
Indeed, the compiler does allow me to write:
---
template test(Object[] o) { enum test = 0; }
void main() { int dummy = test!([new Object]); }
---
without complaint! So wrapping it in an array is fine (this is technically
accepts-invalid since [new Object] is not an array of template value arguments,
but the error is not diagnosed until codegen which means you can smuggle the
value in if you keep it strictly in a CTFE context, but since you can
initialize static object arrays in CTFE for runtime without error, even this
seems silly). But the compiler rejects the immediate object out of hand.
I don't see any reason for this restriction to continue to exist. I can
understand it not accepting a reference since that cannot be read at compile
time and mutable aliases and CTFE are not likely to work well anyway.
But is there a good reason not to allow an object literal?
--
[Issue 21220] [DIP1000] scope variable may escape through scope dynamic array parameter
https://issues.dlang.org/show_bug.cgi?id=21220 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Mathias LANG --- Duplicate of 20505, which is itself a subset of 17764. *** This issue has been marked as a duplicate of issue 20505 *** --
[Issue 20505] [DIP1000] Static array allows to escape references to stack variables
https://issues.dlang.org/show_bug.cgi?id=20505 Mathias LANG changed: What|Removed |Added CC||outland.kar...@gmail.com --- Comment #5 from Mathias LANG --- *** Issue 21220 has been marked as a duplicate of this issue. *** --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 Richard Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #41 from Richard Cattermole --- As of 2.077.1 the memory corrupting example in the original post no longer compiles due to improvements with @safe. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #40 from thomas.bock...@gmail.com --- (In reply to thomas.bockman from comment #39) > Are postblits even still broken? Also, I tested all of the examples posted to this issue. On recent compilers they all seem to either work correctly, or generate a compile-time error with a good message. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 thomas.bock...@gmail.com changed: What|Removed |Added CC||thomas.bock...@gmail.com --- Comment #39 from thomas.bock...@gmail.com --- Is this resolved by DIP 1018's copy constructors, https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md https://dlang.org/spec/struct.html#struct-copy-constructor And the pseudo-deprecation of postblits? https://dlang.org/spec/struct.html#struct-postblit I'm asking because someone on the forums told me not to trust copy constructors to work correctly, and linked me here. Are copy constructors broken too, or just legacy postblits? Are postblits even still broken? If so, shouldn't they be officially deprecated? --
[Issue 21592] two stack traces if high surrogate is printed
https://issues.dlang.org/show_bug.cgi?id=21592 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @aG0aep6G created dlang/phobos pull request #7801 "fix issue 21592 - two stack traces if high surrogate is printed" fixing this issue: - fix issue 21592 - two stack traces if high surrogate is printed https://github.com/dlang/phobos/pull/7801 --
[Issue 15930] min/max of pointers violates const
https://issues.dlang.org/show_bug.cgi?id=15930 --- Comment #2 from Steven Schveighoffer --- Hm... thanks. I wonder if a test case should be added. --
[Issue 21643] If you want to work as a Smart Hands Engineer, we’ve got all the information you need to know before making this career change.
https://issues.dlang.org/show_bug.cgi?id=21643 moonlightsenti...@disroot.org changed: What|Removed |Added Status|NEW |RESOLVED CC||moonlightsentinel@disroot.o ||rg Resolution|--- |INVALID --- Comment #1 from moonlightsenti...@disroot.org --- Spam --
[Issue 21644] job search engines
https://issues.dlang.org/show_bug.cgi?id=21644 moonlightsenti...@disroot.org changed: What|Removed |Added Status|NEW |RESOLVED CC||moonlightsentinel@disroot.o ||rg Resolution|--- |INVALID --- Comment #1 from moonlightsenti...@disroot.org --- Spam --
[Issue 21220] [DIP1000] scope variable may escape through scope dynamic array parameter
https://issues.dlang.org/show_bug.cgi?id=21220 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #12204 "Fix Issue 21220 - [DIP1000] scope variable may escape through scope dynamic array parameter" fixing this issue: - Fix Issue 21220 - [DIP1000] scope variable may escape through scope dynamic array parameter https://github.com/dlang/dmd/pull/12204 --
[Issue 21644] job search engines
https://issues.dlang.org/show_bug.cgi?id=21644 vanajafe changed: What|Removed |Added URL||https://www.fieldengineer.c ||om/blogs/the-absolute-best- ||job-search-websites-around --
[Issue 21644] New: job search engines
https://issues.dlang.org/show_bug.cgi?id=21644 Issue ID: 21644 Summary: job search engines Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: vanajan...@gmail.com job search engines A freelance recruitment portal for field engineers and IT technicians especially, this is a prime example of doing a niche job board right.Upload your resume and the site starts showing listings suited specifically to your skills, making your search even easier. https://www.fieldengineer.com/blogs/the-absolute-best-job-search-websites-around --
[Issue 21110] OOB memory access, safety violation
https://issues.dlang.org/show_bug.cgi?id=21110 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Component|dmd |druntime --
[Issue 21643] New: If you want to work as a Smart Hands Engineer, we’ve got all the information you need to know before making this career change.
https://issues.dlang.org/show_bug.cgi?id=21643 Issue ID: 21643 Summary: If you want to work as a Smart Hands Engineer, we’ve got all the information you need to know before making this career change. Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: srug...@gmail.com The majority of MSO’s in the United States have installed fiber optic lines within their data infrastructure, relying on coaxial cable or copper lines for the last mile. https://www.fieldengineer.com/blogs/light-end-cable --
[Issue 21643] If you want to work as a Smart Hands Engineer, we’ve got all the information you need to know before making this career change.
https://issues.dlang.org/show_bug.cgi?id=21643 srugakm changed: What|Removed |Added URL||https://www.fieldengineer.c ||om/blogs/light-end-cable --
[Issue 21642] [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums
https://issues.dlang.org/show_bug.cgi?id=21642 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @n8sh created dlang/druntime pull request #3376 "[REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums" fixing this issue: - Fix Issue 21642 - [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums https://github.com/dlang/druntime/pull/3376 --
[Issue 21642] New: [REG 2.084] hashOf will fail to compile for some structs/unions that recursively contain shared enums
https://issues.dlang.org/show_bug.cgi?id=21642
Issue ID: 21642
Summary: [REG 2.084] hashOf will fail to compile for some
structs/unions that recursively contain shared enums
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: n8sh.second...@hotmail.com
The following code compiles with DMD 2.067.1 to 2.083.1 but fails to compile on
2.084.1:
---
void main()
{
enum C : char { _ = 1, }
union U { C c; void[0] _; }
shared union V { U u; }
cast(void) hashOf(V.init);
}
---
The underlying issue is a problem with the CTFE path for getting the byte
representation of shared enum members. The following code has never compiled
but that only became a problem after 2.084:
---
void main()
{
import core.internal.convert : toUbyte;
enum C : char { _ = 1, }
shared C c;
cast(void) toUbyte(c);
}
---
--
