[Issue 23919] cast array to pointer should be illegal
https://issues.dlang.org/show_bug.cgi?id=23919 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=6869 --
[Issue 6869] Disallow array to pointer cast
https://issues.dlang.org/show_bug.cgi?id=6869 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23919 --
[Issue 23919] New: cast array to pointer should be illegal
https://issues.dlang.org/show_bug.cgi?id=23919 Issue ID: 23919 Summary: cast array to pointer should be illegal Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: schvei...@gmail.com Casting an array to a pointer is allowed: ```d import core.stdc.stdio; auto str = "hello"; printf(cast(char *)str[0 .. 3]); ``` This prints "hello". The user might think they have properly matched the requirements, but in actuality, all they have done is accessed the pointer. A few reasons why this is bad: 1. It's trivial (and more readable) to use `.ptr` instead of the cast 2. The cast must match the attributes or risk causing problems when code evolves. Casting is a blunt instrument, and should be discouraged when better alternatives exist. 3. The cast gives a false impression that something is happening underneath to ensure the data is correct. Many C functions require pointers instead of arrays, and this "seems" like the right answer. I think we should deprecate this "feature". I'm not exactly sure why this was needed in the first place. I know a previous issue #6869 was closed as WONTFIX. I'm opening this to hopefully reconsider the decision. FWIW, the D discord has had a few people coming to ask why their code doesn't work when casting a `string` to a `char *`. I would pair such a cast error with a suggestion to use `toStringz` in the case of string to char * conversions. --
[Issue 23918] New: Lambdas declared as "function" should be static and not have a context
https://issues.dlang.org/show_bug.cgi?id=23918
Issue ID: 23918
Summary: Lambdas declared as "function" should be static and
not have a context
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
/// test.d ///
struct BobsContext
{
void bobWhoAlreadyHasAContext(alias fun)()
{
fun(1);
}
}
void main()
{
BobsContext b;
// Works:
{
void fun(X)(X x) {}
b.bobWhoAlreadyHasAContext!fun();
}
// Doesn't work:
{
alias fun = function (x) {};
b.bobWhoAlreadyHasAContext!fun();
}
}
//
(DMD currently produces the "function requires a dual-context" deprecation)
Leaving aside the question of why lambdas don't have their need for context
auto-detected like normal template functions... if the user writes the keyword
"function", that should effectively make the lambda static and not require a
context.
If this somehow ends up too much of a breaking change... the "static" keyword
is currently not accepted in lambda / anonymous function literals, but it could
be.
--
[Issue 23917] "ref" in alias this call not detected in "auto ref" return resolution
https://issues.dlang.org/show_bug.cgi?id=23917 --- Comment #2 from Vladimir Panteleev --- (Oops, ignore above comment, got my return types mixed up.) --
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916
--- Comment #2 from Vladimir Panteleev ---
(In reply to Nick Treleaven from comment #1)
> template X() {}
>
> It was decided that typeof(X) is void, that's in the spec. I'm not sure if
> the type of a template instance is defined in the spec.
Any reason not to revise and deprecate this?
> Note: You are allowed to return an expression of type void, this is useful
> in generic code.
Yes. Although, it is an accidental, half-finished feature. You cannot have void
variables or function parameters. Ironically however, you can have noreturn
variables and function parameters.
--
[Issue 23916] Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #1 from Nick Treleaven ---
template X() {}
It was decided that typeof(X) is void, that's in the spec. I'm not sure if the
type of a template instance is defined in the spec. A template instance seems
similar to a module. However `typeof(std.math)` is a compile error.
void fun()
{
return X!();
}
Note: You are allowed to return an expression of type void, this is useful in
generic code.
--
[Issue 23917] "ref" in alias this call not detected in "auto ref" return resolution
https://issues.dlang.org/show_bug.cgi?id=23917
--- Comment #1 from Vladimir Panteleev ---
Something weird also happens when you try to pass it as a parameter to a ref
function. A non-templated function works, but a function templated on the
argument/return type fails!
/ test.d
struct NC { @disable this(this); }
struct A
{
@property ref NC value() { assert(false); }
alias value this;
}
A a;
ref NC f1(ref return NC value) { return value; }
auto ref NC get1() { return f1(a); } // OK
ref T f2(T)(ref return T value) { return value; }
auto ref NC get2() { return f2(a); } // Error
/
--
[Issue 23917] New: "ref" in alias this call not detected in "auto ref" return resolution
https://issues.dlang.org/show_bug.cgi?id=23917
Issue ID: 23917
Summary: "ref" in alias this call not detected in "auto ref"
return resolution
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
// test.d /
struct NC { @disable this(this); }
struct S
{
struct A
{
@property ref NC value() { assert(false); }
alias value this;
}
A a;
auto ref NC get() return
{
return a;
}
}
///
Compiler says:
test.d(14): Error: struct `test.NC` is not copyable because it has a disabled
postblit
However, changing "auto ref" to "ref" makes it work.
--
[Issue 23916] New: Non-eponymous template instances have a "type" (void)
https://issues.dlang.org/show_bug.cgi?id=23916
Issue ID: 23916
Summary: Non-eponymous template instances have a "type" (void)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid, diagnostic
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
This code is meaningless, and should not compile:
test.d
template X() {}
void fun()
{
return X!();
}
Template instances having a type when they shouldn't can be misleading and
confusing to diagnose. For example, consider:
/ test.d /
template X()
{
}
void fun(int i) {}
void main()
{
fun(X!());
}
//
Currently, this produces:
test.d(9): Error: function `test.fun(int i)` is not callable using argument
types `(void)`
test.d(9):cannot pass argument `X!()` of type `void` to parameter `int
i`
A better error would be:
test.d(9): Error: cannot pass template instance `X!()` as a function argument
--
[Issue 23915] New: Instance method properties not evaluated when passed to template value argument
https://issues.dlang.org/show_bug.cgi?id=23915
Issue ID: 23915
Summary: Instance method properties not evaluated when passed
to template value argument
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
test.d ///
template T(bool value) {}
@property bool getValue() { return true; }
alias Inst1 = T!(getValue); // OK
struct S2 { static @property bool getValue() { return true; } }
alias Inst2 = T!(S2.getValue); // OK
struct S3 {@property bool getValue() { return true; } }
alias Inst = T!(S3().getValue); // Error
///
For some reason, free functions and static functions work, but not instance
methods.
Compiler says:
test.d(10): Error: template instance `T!(getValue)` does not match template
declaration `T(bool value)`
test.d(10):`getValue` is not of a value of type `bool`
--
[Issue 23364] returning bottom type by ref should work
https://issues.dlang.org/show_bug.cgi?id=23364 Vladimir Panteleev changed: What|Removed |Added CC||dlang-bugzilla@thecybershad ||ow.net --- Comment #1 from Vladimir Panteleev --- Worked before https://github.com/dlang/dmd/pull/14187 , though I'm not sure if this is something that should work... The conclusion makes sense to me only with a rather literal interpretation of the definition of noreturn in object - we "undo" the null pointer dereference by using "ref". With an alternative definition of noreturn, e.g. `typeof(assert(false))`, I'm not sure that this makes sense any more. --
[Issue 23914] "auto ref" resolution on return value prevented by noreturn (bottom type)
https://issues.dlang.org/show_bug.cgi?id=23914 Vladimir Panteleev changed: What|Removed |Added Summary|"auto ref" resolution |"auto ref" resolution on |prevented by bottom type|return value prevented by ||noreturn (bottom type) --
[Issue 23914] "auto ref" resolution prevented by bottom type
https://issues.dlang.org/show_bug.cgi?id=23914 --- Comment #2 from Vladimir Panteleev --- No. --
[Issue 23914] "auto ref" resolution prevented by bottom type
https://issues.dlang.org/show_bug.cgi?id=23914 mhh changed: What|Removed |Added CC||maxha...@gmail.com --- Comment #1 from mhh --- Isn't `auto ref` for template function parameters only? --
[Issue 23914] "auto ref" resolution prevented by bottom type
https://issues.dlang.org/show_bug.cgi?id=23914 Vladimir Panteleev changed: What|Removed |Added Summary|"auto ref" determination|"auto ref" resolution |prevented by bottom type|prevented by bottom type --
[Issue 23914] New: "auto ref" determination prevented by bottom type
https://issues.dlang.org/show_bug.cgi?id=23914
Issue ID: 23914
Summary: "auto ref" determination prevented by bottom type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
/ test.d /
struct NC { @disable this(this); }
struct S
{
NC nc;
auto ref fun()
{
if (true)
return nc;
else
return assert(false);
}
}
//
Compiler says:
test.d(9): Error: struct `test.NC` is not copyable because it has a disabled
postblit
Looks like it prevented "auto ref" from being resolved into "ref", even though
explicitly returning by ref seems to work.
--
[Issue 23913] __traits(getMember) fails for some C symbols
https://issues.dlang.org/show_bug.cgi?id=23913 Andrej Mitrovic changed: What|Removed |Added Keywords|betterC |ImportC --- Comment #1 from Andrej Mitrovic --- Corrected wrong keyword. --
[Issue 23913] New: __traits(getMember) fails for some C symbols
https://issues.dlang.org/show_bug.cgi?id=23913
Issue ID: 23913
Summary: __traits(getMember) fails for some C symbols
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: betterC
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
This works in v2.102.0 but fails in v2.013.x:
library.c:
```
typedef enum SomeEnum
{
foo = 0,
bar = -1,
} SomeEnum;
```
mod.d:
```
module mod;
import library;
alias x = __traits(getMember, library, "SomeEnum");
```
```
$ dmd -c library.c mod.d
[1]28653 illegal hardware instruction (core dumped) dmd -c library.c mod.d
core.exception.AssertError@src/dmd/expressionsem.d(13055): Assertion failure
```
Specifically:
https://github.com/dlang/dmd/blob/a45f4e9f43e9fdbf0b666175e5e66b1ce4f561f6/compiler/src/dmd/expressionsem.d#L13054
It seems to only fail for typedef'ed enums like this.
--
