[Issue 14250] New: add function for reading a password to std.getopt
https://issues.dlang.org/show_bug.cgi?id=14250 Issue ID: 14250 Summary: add function for reading a password to std.getopt Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Or possibly add a new std.getpass module. There is a python module getpass that nicely implements the needed function. https://docs.python.org/2/library/getpass.html --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #8 from Martin Nowak --- (In reply to Ketmar Dark from comment #7) > so do you mean that if some syntax was allowed by accident, it should be > kept forever No it should be kept for one release with a deprecation warning attached. --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #9 from Dicebot --- It was introduced in 1b932b9282df6ed312b6da0031417ea0d4f8faa5 I am looking in how deprecation message can be added --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #11 from Ketmar Dark --- but why? it's not the compiler task to babysit old and broken code, it's lint(dfix) task. removing that burden from compiler allows alot more possibilities, as compiler code stays clean, and dfix can accumulate alot of checks, allowing easy fixing the code even from the very old compiler release with step-by-step upgrading. i'm far from saying that nothing should be done. actually, i'm saying the exact opposite thing: it's time to bless dfix and bundle it with compiler package, so people can upgrade to new compiler versions without much pain. --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #10 from Martin Nowak --- (In reply to Ketmar Dark from comment #7) Once dfix is ready for primetime and is release with dmd we might switch to a model where we such changes are accompanied with a rewrite in dfix. But for now, it's really unprofessional to suddenly break code. --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #12 from Dicebot --- Can you please resist the temptation to start another pointless discussion with ketmar? I don't want to disable notifications for this issue. --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #13 from Martin Nowak --- Thanks @dicebot. It's this error you're triggering. https://github.com/9rnsr/dmd/commit/1b932b9282df6ed312b6da0031417ea0d4f8faa5#diff-62dcb5f0ffc3089b7565897d8beb3322R918 At best you pass a `bool onlyWarn = false` to `appendStorageClass`, and then pass `true` for places were it didn't previously error. The actual error was introduced here. https://github.com/D-Programming-Language/dmd/pull/3689 Be careful to preserve existing errors. https://github.com/9rnsr/dmd/commit/1b932b9282df6ed312b6da0031417ea0d4f8faa5#diff-62dcb5f0ffc3089b7565897d8beb3322R503 --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #15 from Martin Nowak --- (In reply to Ketmar Dark from comment #11) > i'm far from saying that nothing should be done. actually, i'm saying the > exact opposite thing: it's time to bless dfix and bundle it with compiler > package, so people can upgrade to new compiler versions without much pain. Yes, just like I said. Once dfix is ready and we include it in our release we might modify the policy for such changes. But we include dfix just a few days before a release. How about you work with Brian on getting it integrated for 2.068? --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #14 from Dicebot --- Thanks, working on it. --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #16 from Ketmar Dark --- > How about you work with Brian on getting it integrated for 2.068? i've never seen a call for help from him. but sure, if he needs any help i can provide, i'm ready to do that... after dfix inclusion will be officially approved by Walter and Andrei. working for a trashcan is not fun. --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #17 from Kenji Hara --- (In reply to Martin Nowak from comment #4) > (In reply to Ketmar Dark from comment #3) > > should any bug be deprecated first — just in case somebody wrote invalid > > code relying on that bug? > > Usually yes, but within reason, depending on how complicated it is to fix > the code compared to how complicated the deprecation is. An application of deprecation process will be legitimate only when the deprecated behavior was valid and designed feature in old versions. Accepting redundant attributes had not been documented in language spec, it has been just accidentally accepted. Therefore, consistently disabling them all is a bugfix. Even though it will break some user code suddenly, deprecation process should not be applied. And from a realistic reason, It's difficult. In old dmd version, some of redundancies were properly disallowed, and remaining were (unintentionally) accepted. To deprecate invalid accepted case, we should emulate old unintentional compiler behavior. It's too costly, and I don't want to do it. --
[Issue 10972] aggregate postblit doesn't clean up in case of failure
https://issues.dlang.org/show_bug.cgi?id=10972 Kenji Hara changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #1 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4456 --
[Issue 6766] Forward reference error for default struct/class arguments
https://issues.dlang.org/show_bug.cgi?id=6766 Kenji Hara changed: What|Removed |Added Keywords||pull Hardware|Other |All OS|Windows |All --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4457 --
[Issue 11166] Forward reference error when alias of template instance is private
https://issues.dlang.org/show_bug.cgi?id=11166 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4457 --
[Issue 6766] Forward reference error for default struct/class arguments
https://issues.dlang.org/show_bug.cgi?id=6766 Kenji Hara changed: What|Removed |Added CC||samu...@voliacable.com --- Comment #3 from Kenji Hara --- *** Issue 5223 has been marked as a duplicate of this issue. *** --
[Issue 5223] [qtd] Cannot use default value with function parameter of struct type
https://issues.dlang.org/show_bug.cgi?id=5223 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 6766 *** --
[Issue 14251] New: synchronized (mtx) doesn't check attributes (pure, const)
https://issues.dlang.org/show_bug.cgi?id=14251 Issue ID: 14251 Summary: synchronized (mtx) doesn't check attributes (pure, const) Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: c...@dawg.eu It's possible to run `synchronized (mtx)` in a `pure const` function even though neither of both attributes apply. This happens because the compiler doesn't run semantic on the _d_monitorenter/exit function calls. --
[Issue 7157] Optimiser is O(n^2) w.r.t. function length
https://issues.dlang.org/show_bug.cgi?id=7157 --- Comment #7 from Martin Nowak --- (In reply to Jonathan M Davis from comment #6) > Which trick are you referring to? https://github.com/D-Programming-Language/phobos/pull/2767 --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #18 from Martin Nowak --- (In reply to Kenji Hara from comment #17) > Accepting redundant attributes had not been documented in language spec, it > has been just accidentally accepted. Therefore, consistently disabling them > all is a bugfix. Even though it will break some user code suddenly, > deprecation process should not be applied. No, we shouldn't just break code without good reason. Certain changes that detect latent bugs might be OK (escape analysis), but fixing this error hardly adds any benefit for code owners. It's very trivial to fix though. There are plenty of small issues with dmd and if the compiler doesn't adhere to the specs we can't any programmer to do this instead. > And from a realistic reason, It's difficult. In old dmd version, some of > redundancies were properly disallowed, and remaining were (unintentionally) > accepted. To deprecate invalid accepted case, we should emulate old > unintentional compiler behavior. It's too costly, and I don't want to do it. I understand that, that's why I initially close the report and it's what I meant with comment 4. > Usually yes, but within reason, depending on how complicated it is to fix the > code compared to how complicated the deprecation is. But I'm fine with Dicebot adding a deprecation, if he want's to do it. --
[Issue 14213] Strange deprecated message in std.typecons.Proxy with using method
https://issues.dlang.org/show_bug.cgi?id=14213 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86_64 |All OS|Windows |All --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/phobos/pull/3043/files --
[Issue 14252] New: Erroneous dtor attributes check even if the struct returned immediately
https://issues.dlang.org/show_bug.cgi?id=14252
Issue ID: 14252
Summary: Erroneous dtor attributes check even if the struct
returned immediately
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Following code should work, but doesn't.
struct Variant
{
this(int) pure {}
~this() {} // impure
}
auto makeVar(int n) pure
{
return Variant(1);// line 9
}
void main()
{
auto v = makeVar(1);
}
test.d(9): Error: pure function 'test.makeVar' cannot call impure function
'test.Variant.~this'
--
[Issue 14062] Not pure std.variant.Variant ctor
https://issues.dlang.org/show_bug.cgi?id=14062
Kenji Hara changed:
What|Removed |Added
Hardware|x86 |All
OS|Windows |All
Severity|regression |enhancement
--- Comment #4 from Kenji Hara ---
(In reply to sinkuupump from comment #2)
> Ah, constructor can avoid calling fptr(OpId.destruct) because
> fpr==&handler!void there, so it can be pure. But destructor is still impure.
> Any ideas?
As you say, constructing Variant can be pure depending on the initialized value
type, so it would be an enhancement.
It is more precise test case for the enhancement:
auto makeVar(int n) pure
{
import std.variant: Variant;
return Variant(1); // constructing Variant with int could be pure
}
void main()
{
auto v = makeVar(1);
}
However to support it, a compile bug need to be fixed beforehand.
Issue 14252 - Erroneous dtor attributes check even if the struct returned
immediately
On the other hand, non-algebraic Variant type cannot copy or destruct in pure
function.
Change the importance to 'enhancement'.
--
[Issue 14253] New: [REG2.067b3] std.traits.ParameterStorageClassTuple gives compiler errors when encountering 'return' functions
https://issues.dlang.org/show_bug.cgi?id=14253
Issue ID: 14253
Summary: [REG2.067b3] std.traits.ParameterStorageClassTuple
gives compiler errors when encountering 'return'
functions
Product: D
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: opantm2+db...@gmail.com
Code:
import std.traits;
struct Foo {
ref Foo opAssign(ref Foo rhs) return { return this; }
}
void main() {
alias tup = ParameterStorageClassTuple!(__traits(getOverloads, Foo,
"opAssign")[0]);
}
Output:
/Users/kapps/dev/dmd/phobos/std/traits.d(221): Error: key 'j' not found in
associative array ['a':cast(FunctionAttribute)1u,
'b':cast(FunctionAttribute)2u, 'c':cast(FunctionAttribute)4u,
'd':cast(FunctionAttribute)8u, 'e':cast(FunctionAttribute)16u,
'f':cast(FunctionAttribute)32u, 'i':cast(FunctionAttribute)64u]
/Users/kapps/dev/dmd/phobos/std/traits.d(970):called from here:
demangleFunctionAttributes("NcNjKS4test3FooZS4test3Foo")
/Users/kapps/dev/dmd/phobos/std/traits.d(993):while looking for match
for demangleNextParameter!(__error)
/Users/kapps/test.d(8): Error: template instance
std.traits.ParameterStorageClassTuple!(opAssign) error instantiating
--
