[Issue 21290] [REG2.073] Incorrect escape deprecation on scope lazy pointer parameter
https://issues.dlang.org/show_bug.cgi?id=21290 johanenge...@weka.io changed: What|Removed |Added Keywords||rejects-valid --
[Issue 23667] [REG2.101] Incorrect escape deprecation on scope lazy pointer parameter
https://issues.dlang.org/show_bug.cgi?id=23667 johanenge...@weka.io changed: What|Removed |Added Keywords||industry, rejects-valid --
[Issue 23667] New: [REG2.101] Incorrect escape deprecation on scope lazy pointer parameter
https://issues.dlang.org/show_bug.cgi?id=23667
Issue ID: 23667
Summary: [REG2.101] Incorrect escape deprecation on scope lazy
pointer parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
Testcase:
```
struct S {
this(ref int i) {
DBG();
}
}
void DBG(lazy scope int* args) {}
```
Compilation with dlang2.101 gives the error:
(3): Deprecation: escaping reference to outer local variable `i`
Removing `lazy` makes the code compile.
Note that this is very similar but distinct from
https://issues.dlang.org/show_bug.cgi?id=21290 , because that regression
already appeared from 2.073.
--
[Issue 23662] ImportC bad handling of enum arguments for a function
https://issues.dlang.org/show_bug.cgi?id=23662 --- Comment #1 from Dlang Bot --- @katyukha created dlang/dmd pull request #14859 "Fix Issue 23662: ImportC bad handling of enum arguments for a function" mentioning this issue: - Added testcase for Issue 23662 See: https://issues.dlang.org/show_bug.cgi?id=23662 - [FIX] Issue 23662 https://github.com/dlang/dmd/pull/14859 --
[Issue 21321] Unimplemented interface method from abstract base class not detected
https://issues.dlang.org/show_bug.cgi?id=21321 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Summary|Class with unimplemented|Unimplemented interface |interface method compiles, |method from abstract base |links, then segfaults, if |class not detected |inherited through abstract | |base class | --
[Issue 21321] Class with unimplemented interface method compiles, links, then segfaults, if inherited through abstract base class
https://issues.dlang.org/show_bug.cgi?id=21321 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #8 from Dlang Bot --- @ntrel updated dlang/dmd pull request #14853 "Fix 2525: check all parent interfaces for overriden methods" fixing this issue: - Fix Issue 21321 - Unimplemented interface method from abstract base class Add test case. Note: unimplemented abstract method not detected. https://github.com/dlang/dmd/pull/14853 --
[Issue 23666] Recognize template opApply pattern
https://issues.dlang.org/show_bug.cgi?id=23666 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 23666] New: Recognize template opApply pattern
https://issues.dlang.org/show_bug.cgi?id=23666
Issue ID: 23666
Summary: Recognize template opApply pattern
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
Normally, when `opApply` is a template, `foreach` variable types cannot be
inferred and must be stated explicitly. I propose an exception to this rule to
make implementing `opApply` with respect to attributes (safe, nogc, pure,
nothrow) easier[1, 2].
Basic idea: Make `opApply` a template to infer attributes based on the delegate
argument’s type. If `opApply` is a template with a single template type
parameter that is used as the type of the single function parameter and is
additioanlly constrained to a delegate type, we can use that type to infer
`foreach` variable types.
A minimal example:
```d
struct S
{
int opApply(DG : int delegate(int))(DG dg)
{
return 0;
}
}
void main() @safe
{
foreach (x; S()) // infer `int` for x
{ }
}
```
Details:
When all `opApply` function templates in an aggregate have as their first
template parameter a type parameter that is “aptly” constrained[5] (“aptly”
defined blow), the respective instantiations with the constraint type are valid
(i.e. instantiate `opApply(DG : Constraint)` as `opApply!Constraint`), and the
resulting template instance (a member function) can be called with 1 argument
of the type of the constraint (i.e. `opApply!Constraint(Constraint.init)`
compiles), these member function templates are added to non-template `opApply`
member functions used to determine `foreach` types.
To be “aptly constrained” means that the constraint is a type of the following
form:
```d
int delegate ParameterList MemberFunctionAttributes`
```
where `ParameterList` and `MemberFunctionAttributes` [3, 4] are defined in the
D grammar.
The parameters of the `ParameterList` in an “apt” constraint are considered
together with `ParameterList`s of non-template `opApply(int delegate
ParameterList MemberFunctionAttributes)` (if any) to find the best match in
terms of number and `ref`-ness. If the best match for a given `foreach`
statement is such a template instance, it is instantiated again with the type
of the `foreach` lambda, where the types of the `foreach` body lambda’s
parameters are set to the types determied by the constraint in the `opApply`
template.
A template `opApply` may have more than one template parameter and more than
one function parameter when the additional parameters have defaults.
[1] Relevant thread:
https://forum.dlang.org/thread/zlzhrzzamwkohturh...@forum.dlang.org
[2] Relevant post:
https://forum.dlang.org/post/uquebghlhhstkuxtu...@forum.dlang.org
[3] https://dlang.org/spec/function.html#Parameters
[4] https://dlang.org/spec/function.html#MemberFunctionAttributes
[5] https://dlang.org/spec/template.html#Constraint
--
[Issue 23665] Add traits
https://issues.dlang.org/show_bug.cgi?id=23665 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 23665] New: Add traits
https://issues.dlang.org/show_bug.cgi?id=23665
Issue ID: 23665
Summary: Add traits
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
Add `__traits` to expose information about a template’s parameters: A template
parameter has the following properties:
1. An identifier.
2. A kind: It is a value parameter, a type parameter, an alias parameter, or a
sequence parameter. Arguably, a template `this` parameter is a type parameter,
but IMO, it should be its own kind.
3. A type if it is a value parameter. (Alias and sequence parameters can be
bound to value arguments that have types, but the parameter itself has no
type.)
4. Optionally a constraint.
5. Optionally a default.
Chellanges:
1. Only values have types.
2. Types, constraints, and defaults might not be accessible, a symbolic (not a
string) return is useful.
3. Types, constraints, and defaults can be dependent on previous paramters; a
symbolic return is not possible in that case.
Proposed specification:
First, provide the trait `templateParameterLength` taking an alias to a
template that returns the number of (lexical) template parameters. (By lexical,
I mean that a sequence parameter counts as exactly 1 parameter, even if
logically, it is “0 or many”.)
Note: For the following that take an index, if the index is out of range (≥
`templateParameterLength`), it is a compile error. The wording assumes that the
index is in range.
For each template parameter property, provide a trait named
`templateParameter(Identifier|Kind|Type|Constraint|Default)`, respectively,
taking an alias to a template and an index that returns compile-time
information of the respective properties (if available – a parameter might not
have a type, constraint, or default).
E.g. `__traits(templateParameterKind, std.meta.AliasSeq, 0)` returns the kind
of the only parameter: sequence.
Also provide the trait `templateParameterHas(Type|Constraint|Default)` taking
an alias to a template and an index that returns a bool providing information
about the availability of that property:
`templateParameterHasType` is a compile-error when the parameter is not of kind
value. (The programmer should use `static if` to enusre the parameter queried
is of kind value.) It returns `true` if the type is independent of previous
template parameters and `false` if it is dependent on them. (This might be a
best-effort, i.e. there could be edge cases in which `false` could be returned
when `true` is actually possible.)
`templateParameterHas(Constraint|Default)` returns returns `true` if the
template parameter has a constraint or default, respectively.
Identifiers are returned as strings (cf. `__traits(identifier)`). Unnamed
parameters are syntactically not possible, the string is never empty or `null`.
The kind could be designated by a finite set of strings ("value", "type",
"alias", "sequence", and "this") or by values of an `enum`.
`__traits(templateParameterType)` returns a sequence consisting of 1 or 2
entries: The first entry is the string used to define the parameter; the second
entry is present and an alias to the type when
`__traits(templateParameterHasType)` is `true` (and thus the type is
well-defined).
For constraints and defaults, `__traits(templateParameter(Constraint|Default))`
compiles if `__traits(templateParameterHas(Constraint|Default))` is `true`.
Because constraints and defaults can depend on previous parameters, they cannot
always be extracted symbolically. Again, a sequence consisting of 1 or 2
entries is returned: The first entry is the string consisting of the tokens
making up the constraint/default, the second is present if the
constraint/default is independent of previous parameters and thus can be
extracted symbolically.
--
[Issue 20077] Bogus 'need this' for lambda used inside struct
https://issues.dlang.org/show_bug.cgi?id=20077 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@gmail.com Hardware|x86 |All OS|Windows |All --
[Issue 23664] New: Infer `const` for lambdas/closures
https://issues.dlang.org/show_bug.cgi?id=23664 Issue ID: 23664 Summary: Infer `const` for lambdas/closures 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 Attributes (`@safe`, `pure`, etc.) are inferred for lambdas, but a delegate can also specify a type constructor (or a combination such as `inout const`). Because the implementation of the lambda is always known, the compiler can figure out if the delegate is in fact * `immutable`, i.e. all data it accesses through its context (if any) is `immutable`. * `const`, i.e. all the accessed data in its context (if any) is not changed by the delegate (think of: the delegate only calls free functions and `const` member functions on things it accesses). Note that type constructors in this case are purely additional information, the same way `@safe`, `pure`, `nothrow`, or `@nogc`. This means that forgetting them won’t make using the delegate invalid; only the context it’s used in might require them. (This requires that the implicit conversion of `immutable` to `const` and `immutable`/`const` to mutable for delegate context type constructors is implemented. --
[Issue 23664] Infer `const` for lambdas/closures
https://issues.dlang.org/show_bug.cgi?id=23664 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 9149] Disallow converting delegates to const
https://issues.dlang.org/show_bug.cgi?id=9149 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 18830] Document Allowance for "new" with "scope" in @nogc Functions
https://issues.dlang.org/show_bug.cgi?id=18830 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dlang.org pull request #3515 "Fixed issue 18830 - document "new" with "scope" in @nogc Functions" was merged into master: - 9d04378250a90b506bf1ed22ff35d35edd762589 by RaresCon: Fixed issue 18830 - document "new" with "scope" in @nogc Functions - f5706c8e76ff48c92dd1e5e3ba7bcccb4e114a2f by RaresCon: Fix Issue 18830 - document "new" with "scope" in @nogc Functions https://github.com/dlang/dlang.org/pull/3515 --
[Issue 16707] [Templates] run variadic templates example failed
https://issues.dlang.org/show_bug.cgi?id=16707 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dlang.org pull request #3516 "Fix issue 16707" was merged into master: - 8f33642546b9163478e56d5f6a49ef8fbaae6015 by Drehuta Andreea: Fix issue 16707 https://github.com/dlang/dlang.org/pull/3516 --
[Issue 11493] dlang.org/type.html incorrectly says that you can't cast from -1 to unsigned types
https://issues.dlang.org/show_bug.cgi?id=11493 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3517 "Fix issue 11493 - Correctly explain code snippet behaviour" was merged into master: - deb0d0a8328f79223906d13aed8964f43663281b by Matei Hriscu: Fix 11493 - correctly explain code snippet behaviour Signed-off-by: Matei Hriscu https://github.com/dlang/dlang.org/pull/3517 --
[Issue 11493] dlang.org/type.html incorrectly says that you can't cast from -1 to unsigned types
https://issues.dlang.org/show_bug.cgi?id=11493 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @matthriscu created dlang/dlang.org pull request #3517 "Fix issue 11493 - Correctly explain code snippet behaviour" fixing this issue: - Fix 11493 - correctly explain code snippet behaviour Signed-off-by: Matei Hriscu https://github.com/dlang/dlang.org/pull/3517 --
[Issue 6949] no warning or error if unsigned variable is compared to 0
https://issues.dlang.org/show_bug.cgi?id=6949 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #20 from RazvanN --- Implementing what is asked in this bug report leads to code breakage (assuming we issue an error and not a warning) of otherwise valid code. Walter opposed this in the PR so I am going to close this as WONTFIX. --
[Issue 4936] Better error when type inference fails due to incorrect template parameter type
https://issues.dlang.org/show_bug.cgi?id=4936 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #7 from RazvanN --- Right now the error is: Error: none of the overloads of template `std.algorithm.sorting.completeSort` are callable using argument types `!()(string[], string[])` Candidate is: `completeSort(alias less = "a < b", SwapStrategy ss = SwapStrategy.unstable, Lhs, Rhs)(SortedRange!(Lhs, less) lhs, Rhs rhs)` So it is pointing the declaration and it can be observed that `foo` is not SortedRange. --
[Issue 4907] Catching more simple out-of-bounds errors at compile-time
https://issues.dlang.org/show_bug.cgi?id=4907 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from RazvanN --- Well, this check amounts to adding a special case in the compiler for no apparent benefit since you end up with an assertion error at runtime anyway. I don't think this is worth it. --
[Issue 16707] [Templates] run variadic templates example failed
https://issues.dlang.org/show_bug.cgi?id=16707 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @AndreeaDrehuta created dlang/dlang.org pull request #3516 "Fix issue 16707" fixing this issue: - Fix issue 16707 https://github.com/dlang/dlang.org/pull/3516 --
[Issue 22348] Specify forward referencing of MixinDeclaration
https://issues.dlang.org/show_bug.cgi?id=22348 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3513 "Fixed issue 22348 - Specify forward referencing of MixinDeclaration" was merged into master: - e756ec366b6606f08dcf6122f58e2de4ec2cb1ae by Robert Grancsa: Fixed issue 22348 - Specify forward referencing of MixinDeclaration Signed-off-by: Robert Grancsa - 47bcad87c65f340379887659e9306649d6fc6ebf by Robert Grancsa: Fix Issue 22348 - Specify forward referencing of MixinDeclaration Signed-off-by: Robert Grancsa https://github.com/dlang/dlang.org/pull/3513 --
[Issue 18830] Document Allowance for "new" with "scope" in @nogc Functions
https://issues.dlang.org/show_bug.cgi?id=18830 --- Comment #2 from Dlang Bot --- @RaresCon created dlang/dlang.org pull request #3515 "Fixed issue 18830 - document "new" with "scope" in @nogc Functions" mentioning this issue: - Fixed issue 18830 - document "new" with "scope" in @nogc Functions https://github.com/dlang/dlang.org/pull/3515 --
