[Issue 15227] std.format undocumented grammar

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15227

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Dlang Bot  ---
@berni44 created dlang/phobos pull request #7927 "Fix Issue 15227 - std.format
undocumented grammar" fixing this issue:

- Fix Issue 15227 - std.format undocumented grammar

https://github.com/dlang/phobos/pull/7927

--


[Issue 21783] Add `if` as an operator

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21783

--- Comment #1 from Bolpat  ---
It should have read:

> The best I could come up with is
> 
> rhs ? lhs : true
> 
> which [...]

--


[Issue 21783] Add `if` as an operator

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21783

Bolpat  changed:

   What|Removed |Added

 CC||qs.il.paperi...@gmail.com

--


[Issue 21783] New: Add `if` as an operator

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21783

  Issue ID: 21783
   Summary: Add `if` as an operator
   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

Make `if` a binary infix operator on the same precedence level as the trinary
operator. Its semantics would be: (lhs if rhs) is lowered to (!(rhs) || lhs).

The big win is when stating invariants or preconditions and especially
post-conditions. IMO, those should be easy to understand for the common
programmer. The alternatives are just bad as they aren't grasped as an
implication (usually, one goes the route over the rewrite above). The best I
could come up with is

lhs ? rhs : true

which at least uses something that is recognized as an implication.

As an example, this could be the contracted version of a divMod implementation:

void divMod(int a, int b, int q, int r)
in (b > 0)
out (; q <= 0 if a < 0)
out (; q >= 0 if a > 0)
out (; r <= 0 if a < 0)
out (; r >= 0 if a > 0)
{ ... }

I find it really hard to formulate these in a comprehensive manner without an
`if` operator.

--


[Issue 21782] Add version variants for all cmd-line option checks

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21782

Bolpat  changed:

   What|Removed |Added

 CC||qs.il.paperi...@gmail.com

--


[Issue 21782] New: Add version variants for all cmd-line option checks

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21782

  Issue ID: 21782
   Summary: Add version variants for all cmd-line option checks
   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

Using DMD command-line options,[1] one can (en/dis)able certain checks. Using a
version statement, one can conditionally compile code depending on *some* of
these options.

D should provide a version identifier (or keyword) for *every* check. That
identifier or keyword is exactly what it is in [1], and additionally, for every
version identifier/keyword stated, another equivalent identifier should be
available that starts with "check", in particular, I propose the following
names: checkAsserts, checkBounds, checkInContracts, checkInvariants,
checkOutContracts, checkFinalSwitch.

[1] https://dlang.org/dmd-windows.html#switch-check

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

--- Comment #6 from moonlightsenti...@disroot.org ---
Even worse when removing the immutable from S and using const parameters:

extern(C) void puts(const scope char*);

struct S { }

struct Nullable {
S get_() { return S.init; }
deprecated alias get_ this;
}

void foo(const Nullable) { puts("Nullable"); }
void foo(const S) { puts("S"); }

void main() {
foo(Nullable()); // fails due to ambiguity
}

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

--- Comment #5 from moonlightsenti...@disroot.org ---
The regression refers to the change which overload is called, not the
deprecation message.

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

--- Comment #4 from moonlightsenti...@disroot.org ---
(In reply to FeepingCreature from comment #2)
> That's not really a "regression" - well, it is a regression, but it's an

This is still a regression. DMD should prefer const-conversions over implicit
conversions (e.g. alias this).

This extends example exhibits wrong behaviour since 2.061 :
(Unless i misunderstood the rules for overload matching)

extern(C) void puts(const scope char*);

immutable struct S { }

struct Nullable {
S get_() { return S.init; }
deprecated alias get_ this;
}

void foo(immutable Nullable) { puts("Nullable"); }
void foo(immutable S) { puts("S"); }

void main() {
foo(Nullable()); // prints "S"
}

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

--- Comment #3 from FeepingCreature  ---
Oh wait you're right! I thought you were talking about std.typecons.Nullable
for a second.

It's still not a regression - it's a bugfix:
https://issues.dlang.org/show_bug.cgi?id=20033 , I believe.

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

--- Comment #2 from FeepingCreature  ---
That's not really a "regression" - well, it is a regression, but it's an
expected regression, because Nullable's alias get this is in the process of
being deprecated and has been removed in master. A deprecation is functionally
equivalent to a regression, that's why there was a year of warning messages.

--


[Issue 21781] New: [Oh No! Page Not Found] Links to core libs from Better C

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21781

  Issue ID: 21781
   Summary: [Oh No! Page Not Found] Links to core libs from Better
C
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: minor
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: andrewlbu...@gmail.com

The page on Better C (https://dlang.org/spec/betterc.html) links to:
https://dlang.org/phobos/core_sync.html
https://dlang.org/phobos/core_thread.html

both of which say "Oh no! Page not found"

--


[Issue 20705] `-preview=rvaluerefparam` does not work with template deduction

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20705

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@thewilsonator created dlang/dmd pull request #12318 "Fix issue 20705 -
`-preview=rvaluerefparam` does not work with templa…" fixing this issue:

- Fix issue 20705 - `-preview=rvaluerefparam` does not work with template
deduction

https://github.com/dlang/dmd/pull/12318

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

--- Comment #1 from moonlightsenti...@disroot.org ---
This is actually a regression. Extending your example with appropriate
puts("Nullable") / puts("S") yields:

Up to  2.060  : Success with output: Nullable

2.061   to 2.075.1: 

2.076.1 to 2.087.1: Success with output: S
Since  2.088.1: Success with output:
-
onlineapp.d(14): Deprecation: `alias get_ this` is deprecated
S
-

--


[Issue 21780] alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

moonlightsenti...@disroot.org changed:

   What|Removed |Added

Summary|deprecation warning for |alias this preferred over
   |considered but unused alias |immutable conversion even
   |this|if alias this is deprecated
   ||and de is on

--


[Issue 21780] deprecation warning for considered but unused alias this

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

moonlightsenti...@disroot.org changed:

   What|Removed |Added

 CC||moonlightsentinel@disroot.o
   ||rg
   Hardware|x86_64  |All
Summary|alias this preferred over   |deprecation warning for
   |immutable conversion even   |considered but unused alias
   |if alias this is deprecated |this
   |and de is on|
 OS|Linux   |All
   Severity|trivial |regression

--


[Issue 21780] New: alias this preferred over immutable conversion even if alias this is deprecated and de is on

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=21780

  Issue ID: 21780
   Summary: alias this preferred over immutable conversion even if
alias this is deprecated and de is on
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: default_357-l...@yahoo.de

Consider the following code:

immutable struct S { }

struct Nullable {
S get_() { return S.init; }
deprecated alias get_ this;
}

void foo(immutable Nullable) { }
void foo(immutable S) { }

void main() {
foo(Nullable());
}

So `Nullable()` is implicitly convertible to `immutable Nullable` without
hitting the "alias this". And yet, DMD will prefer the deprecated conversion
even if `-de` is on, erroring with

Deprecation: `alias get_ this` is deprecated

This despite the fact that removing the `alias get_ this` will allow the code
to compile.

Marked as trivial because as you can guess from the struct name, this issue
will solve itself "naturally" when 2.097 releases. :)

--


[Issue 13340] Improve error message for overload resolution error

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13340

Nicholas Wilson  changed:

   What|Removed |Added

 CC||iamthewilsona...@hotmail.co
   ||m

--- Comment #1 from Nicholas Wilson  ---
That second `void f()` should be called something different. Renaming it yields

onlineapp.d(20): Error: template `onlineapp.x` cannot deduce function from
argument types `!()(S)`, candidates are:
onlineapp.d(11):`x(T)(T value)`
  with `T = S`
  must satisfy the following constraint:
`   !is(T == struct)`
onlineapp.d(14):`x(T)(ref T value)

_even with_ -preview=rvaluerefparam

so it seems this issue should be closed and another one opened for the fact
that this still doesn't compile?

--


[Issue 13430] Improve error message with wrong arg type to inout function

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13430

Nicholas Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||iamthewilsona...@hotmail.co
   ||m
 Resolution|--- |WORKSFORME

--- Comment #1 from Nicholas Wilson  ---
This seems to have been fixed somewhere along the way. It now prints

onlineapp.d(14): Error: function `onlineapp.S.f(int x) inout` is not callable
using argument types `(ulong)`
onlineapp.d(14):cannot pass argument `s` of type `ulong` to parameter
`int x`

--


[Issue 16472] Spurious "is used as a type" when aliasing enum template as default parameter

2021-03-29 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16472

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Dlang Bot  ---
@thewilsonator created dlang/dmd pull request #12316 "Fix issue 16472: Spurious
"is used as a type" when aliasing enum temp…" fixing this issue:

- Fix issue 16472: Spurious "is used as a type" when aliasing enum template as
default parameter

https://github.com/dlang/dmd/pull/12316

--