[Issue 23913] __traits(getMember) fails for some C symbols
https://issues.dlang.org/show_bug.cgi?id=23913 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @WalterBright created dlang/dmd pull request #15234 "fix Issue 23913 - __traits(getMember) fails for some C symbols" fixing this issue: - fix Issue 23913 - __traits(getMember) fails for some C symbols https://github.com/dlang/dmd/pull/15234 --
[Issue 23409] ImportC: multiple usages of va_list produces garbage
https://issues.dlang.org/show_bug.cgi?id=23409 --- Comment #5 from dave287...@gmail.com --- (In reply to Walter Bright from comment #4) > The problem probably has to do with putting va_start and va_end in a loop. I > think it was written expecting it to be done only once. The same problem occurs with manually unrolling the loop. --
[Issue 23409] ImportC: multiple usages of va_list produces garbage
https://issues.dlang.org/show_bug.cgi?id=23409 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright --- The problem probably has to do with putting va_start and va_end in a loop. I think it was written expecting it to be done only once. --
[Issue 23921] New: The compiler is too pessimistic on how a double context might be required
https://issues.dlang.org/show_bug.cgi?id=23921
Issue ID: 23921
Summary: The compiler is too pessimistic on how a double
context might be required
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
The following code
```
class A
{
void f()
{
class B : A
{
override void f()
{
class C : B
{
override void f()
{
class D : C
{
override void f()
{
}
}
D abcd;
}
}
C abc;
}
}
B ab;
}
}
```
is rejected with
> A.f.B.f.C` is nested within `f`, but super class `B` is nested within `f`
But the very similar
```
class A
{
void f()
{
static class B : A
{
override void f()
{
static class C : B
{
override void f()
{
static class D : C
{
override void f()
{
}
}
D abcd;
}
}
C abc;
}
}
B ab;
}
}
```
is accepted.
--
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916 --- Comment #9 from Vladimir Panteleev --- (In reply to Nick Treleaven from comment #7) > > Wouldn't something more explicit be much better? > > Such as what? For the specific example above, probably this: void f(alias a)() if (is(typeof(a.i) : int)) or: void f(alias a)() if (is(typeof(writeln(a.i depending on your intention. --
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916 --- Comment #8 from Vladimir Panteleev --- (In reply to Nick Treleaven from comment #7) > Can you give examples of confusing code? I find your examples above confusing. It is meaningless for a template to have a type. It is also meaningless for a template instance to have a type, unless of course it is an eponymous template which resolves to something that has a type. "void" is an arbitrary choice. Why the unit type? Why not the bottom type? Why not typeof(null), etc.? > First, you should acknowledge that the constraint is not meaningless as you > said. The usefulness of that constraint is independent of this issue. > > Next, the reader should understand constraints. They don't have to know that > a template instance has void type, yet their code will magically work for > people who do know that. I have no idea what you're trying to say by this. > > Wouldn't something more explicit be much better? > > Such as what? To check that something is a type: if (is(X)) To check that something is a template: if (__traits(isTemplate, X)) To check that something is a template instance: if (is(X : Template!Args, alias Template, Args...)) (or use alias parameter destructuring) To check that something is an instance of a particular template: if (__traits(isSame, TemplateOf!X, SomeTemplate)) Yeah, these are also awkward and inconsistent. std.traits does have a bunch of helpers, such as `isType`, and there've been proposals to put something more readable on top of IsExpression in Phobos. > You are asking for a change so the burden is on you to justify it. If you > like, make a draft pull request and see if it breaks anything. What is this, 90's newsgroups? I'm not playing this "burden of proof" BS. There is nothing personal about this issue. We do not file requests that we are personally "asking for"; we file proposals on how to progress on our shared goal of making the language better. And bugs. Every single bit of the language spec needs to be be defensible. If something is not backed by a strong rationale, it is candidate for revision, and we do need to continuously attack and revise the weak parts of the language. Otherwise, we are never going to get a better language. And yeah, fixing this will probably require a deprecation cycle. --
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916 --- Comment #7 from Nick Treleaven --- Can you give examples of confusing code? > How does it tell that to the reader, unless the reader is aware of this weird > quirk in the language? First, you should acknowledge that the constraint is not meaningless as you said. The usefulness of that constraint is independent of this issue. Next, the reader should understand constraints. They don't have to know that a template instance has void type, yet their code will magically work for people who do know that. > Wouldn't something more explicit be much better? Such as what? > What is the real use case? You are asking for a change so the burden is on you to justify it. If you like, make a draft pull request and see if it breaks anything. --
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916 --- Comment #6 from Vladimir Panteleev --- (In reply to Nick Treleaven from comment #5) > It checks if `a` has a type. It tells the reader that `a` is not a module or > a type itself. Am I missing something? How does it tell that to the reader, unless the reader is aware of this weird quirk in the language? Wouldn't something more explicit be much better? What is the real use case? Do you have any real-world code which illustrates why this rule in the language is useful? > Why is it a problem if a template instance has a type? It allows (accidentally, or maliciously) writing working but confusing code, and allows accidentally writing non-working code which is difficult to diagnose why it's not working. --
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916 --- Comment #5 from Nick Treleaven --- It checks if `a` has a type. It tells the reader that `a` is not a module or a type itself. Why is it a problem if a template instance has a type? --
[Issue 6869] Disallow array to pointer cast
https://issues.dlang.org/show_bug.cgi?id=6869 Salih Dincer changed: What|Removed |Added CC||sali...@hotmail.com --- Comment #5 from Salih Dincer --- So are we going to see the problem reported here as a compilation error? --
[Issue 23920] New: object.require modifies AA before populating value
https://issues.dlang.org/show_bug.cgi?id=23920
Issue ID: 23920
Summary: object.require modifies AA before populating value
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
// test.d //
void main()
{
int[int] aa;
try
aa.require(5, {
if (true)
throw new Exception("oops");
else
return 1;
}());
catch (Exception e) {}
assert(5 !in aa);
}
This allows bypassing the type system, as it allows the "construction" of types
with `@disable this();`.
--
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916
--- Comment #3 from Nick Treleaven ---
> Any reason not to revise and deprecate this?
It would break code like this:
import std.stdio;
template t()
{
int i;
}
void f(alias a)() if (is(typeof(a)))
{
writeln(a.i);
}
void main()
{
alias a = t!();
f!a();
}
--
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916 --- Comment #4 from Vladimir Panteleev --- (In reply to Nick Treleaven from comment #3) > void f(alias a)() if (is(typeof(a))) This looks meaningless to me. Why would you want to write code like this - what is the constraint even supposed to check? Why should we not deprecate then remove taking the type of a template / template instance? --
