A horrible alternative would be to use `alias` on `size_t` to
make up a new pseudo-type that is more aligned with the code
logic.
```
alias integer = size_t;
import std.stdio : writefln;
void main() {
auto arr = [
[5, 15], // 20
[2, 3, 2, 3], // 10
[3, 6, 2, 9]
Well all these proposals to `int` index like `size_t` and `const
typeof(arr.length)` are cryptic and less readable and less
straightforward in comparison to how it used to be. Feels like
horrible decision if the language is suppose to be somewhat
futureproof. The `int` was simple, straighforwar
On Friday, 3 May 2024 at 15:19:13 UTC, user1234 wrote:
On Friday, 3 May 2024 at 14:59:57 UTC, BoQsc wrote:
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:
[...]
So how would you update this example, what is the right index
type here to choose?
```
import std.stdio : writefln;
vo
On Friday, 3 May 2024 at 14:59:57 UTC, BoQsc wrote:
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:
[...]
**You can specify the index type, just choose the right one.**
For now there's a deprecation message but after some
On Friday, 3 May 2024 at 13:18:02 UTC, user1234 wrote:
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:
Why am I forced to visit this D Lang thread, why this
deprecation warning still appears in my console window in the
latest version of DMD. Does not make any sense from the
developer&#
On Friday, 3 May 2024 at 10:50:03 UTC, BoQsc wrote:
Why am I forced to visit this D Lang thread, why this
deprecation warning still appears in my console window in the
latest version of DMD. Does not make any sense from the
developer's perspective to show this warning and pollute the
al
Why am I forced to visit this D Lang thread, why this deprecation
warning still appears in my console window in the latest version
of DMD. Does not make any sense from the developer's perspective
to show this warning and pollute the already polluted logging
entries of the compiler. How
Member, Enum, m);");
}
};
```
Correction: The code shown above actually *does* work properly
without any deprecation warnings. I made a mistake with the enum
being set to the CTFE function I was previously using instead of
this template. This template actually works.
I posted here for visibili
Well, someone on the Discord server has been helping me attempt
this, but while I managed to get a solution that compiles without
errors, I still get the deprecation warning.
Here is what I ended up with:
```
template enumMixin(alias Enum) {
static foreach(m; __traits(allMembers, Enum
I know that DStep generates CTFE functions to automatically make
aliases for enum members so that the can be used without the enum
name, as is done in C. DStep does it with a CTFE function, though
it should also be possible with a mixin template.
Here is my attempt so far, using a mixin templa
On Wednesday, 17 May 2023 at 08:00:17 UTC, Dom DiSc wrote:
If you want auto-conversion, you should be more explicit:
```d
float opCast() { }
```
because if you return "auto" it is not the highest-prio fit and
therefore not chosen.
If you have multiple choices, you still don't need to use
"auto"
On Friday, 12 May 2023 at 15:00:48 UTC, Salih Dincer wrote:
```d
struct Fraction {
int num, den;
this(int n, int d)
{
num = n;
den = d;
}
// Cast Expression : convert float value of fraction
auto opCast(T : float)(
On Sunday, 7 May 2023 at 21:04:05 UTC, Inkrementator wrote:
Open question to everybody: What you're opinion on using opCast
for this? Since it's a type conversion, it seems fitting to me.
Can't converting without explicitly specifying in D is a big
shortcoming in my opinion. There is such a th
On Wed, May 10, 2023 at 10:57:13PM +, Chris Piker via Digitalmars-d-learn
wrote:
> On Wednesday, 10 May 2023 at 20:25:48 UTC, H. S. Teoh wrote:
> > On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via
> > Digitalmars-d-learn wrote: [...]
> > I also suffer from left/right confusion, and al
On Wednesday, 10 May 2023 at 20:25:48 UTC, H. S. Teoh wrote:
On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via
Digitalmars-d-learn wrote: [...]
I also suffer from left/right confusion, and always have to
pause to think about which is the right(!) word before uttering
it.
Oh, I though wa
On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via Digitalmars-d-learn
wrote:
[...]
> My problem with the terms lvalue and rvalue is much more basic, and is
> just a personal one that only affects probably 0.1% of people. I just
> can't keep left vs. right straight in real life. "Right" i
On Wednesday, 10 May 2023 at 16:01:40 UTC, H. S. Teoh wrote:
x = y;
^ ^
| |
lvalue rvalue
...
// This is OK:
x = y + 1;
// This is not OK:
(y + 1) = x;
Thanks for the clear explanation.
My problem with the ter
On Wed, May 10, 2023 at 03:24:48PM +, Chris Piker via Digitalmars-d-learn
wrote:
[...]
> It's off topic, but I forget why managing memory for rvalues* was
> pushed onto the programmer and not handled by the compiler. I'm sure
> there is a good reason but it does seem like a symmetry breaking
On Wednesday, 10 May 2023 at 14:42:50 UTC, Inkrementator wrote:
On Sunday, 7 May 2023 at 21:12:22 UTC, Chris Piker wrote:
https://gist.github.com/run-dlang/9b7aec72710b1108fc8277789776962a
Thanks for posting that. Reading over the code I'm reminded that
I never cared whether something was an
On Sunday, 7 May 2023 at 21:12:22 UTC, Chris Piker wrote:
On the other hand, your first suggestion of using opCast() does
seem like a reasonable choice to me. Can you provide a short
code snippet using opCast to achieve the same result?
I've never used it, and particularly I know that I don't
On 5/7/23 13:44, Chris Piker wrote:
> to fix the problem I
> just delete the alias this line from dpq2, see what unit tests and app
> code it breaks, then fix each of those.
Yes but I neglected the lvalue/rvalue issue. In some cases the code
won't compile if the return type of the newly written
On Sunday, 7 May 2023 at 21:04:05 UTC, Inkrementator wrote:
On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
alias this is for implicit type conversions, which can be
achieved explicitly as well.
Open question to everybody: What you're opinion on using opCast
for this? Since it's a t
On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
alias this is for implicit type conversions, which can be
achieved explicitly as well.
Open question to everybody: What you're opinion on using opCast
for this? Since it's a type conversion, it seems fitting to me.
And another suggest
On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
auto main() {
auto c = new C();
// The same type conversion is now explicit:
foo(c.asIntPtr);
}
Hi Ali
Ah, very clear explanation, thanks! So basically to fix the
problem I just delete the alias this line from dpq2, see w
On 5/7/23 10:55, Chris Piker wrote:
> According to dmd 2.103, alias this is
> deprecated for classes, so I'd like to correct the problem.
alias this is for implicit type conversions, which can be achieved
explicitly as well. Given the following old code:
class C {
int* result;
alias
e PGresult* result;
alias result this; //<---- Deprecation Warning Here
package this(immutable PGresult* r)
{
assert(r);
result = r;
version(Dpq2_Dynamic) dynLoaderRefCnt =
ReferenceCounter(true);
}
...
```
Thanks for any pointers,
On Thursday, 20 April 2023 at 09:41:13 UTC, Dennis wrote:
On Thursday, 20 April 2023 at 09:14:48 UTC, Jack Applegame
wrote:
Can anyone help me get rid of this depreciation?
Annotate `getFoo` with `return scope`:
```d
struct Foo {
string foo;
string getFoo() return scope const
On Thursday, 20 April 2023 at 09:14:48 UTC, Jack Applegame wrote:
Can anyone help me get rid of this depreciation?
Annotate `getFoo` with `return scope`:
```d
struct Foo {
string foo;
string getFoo() return scope const @safe { return foo; }
}
preview=in --run foo.d
foo.d(9): Deprecation: scope variable `foo` assigned to non-scope
parameter `this` calling `getFoo`
```
```sh
$ ldc2 --version
LDC - the LLVM D compiler (1.32.1):
based on DMD v2.102.2 and LLVM 15.0.7
```
On Thursday, 9 March 2023 at 06:36:18 UTC, IchorDev wrote:
On Thursday, 9 March 2023 at 00:21:02 UTC, WhatMeWorry wrote:
[...]
Sorry about that. Try updating to bindbc-glfw 1.0.2, should be
fixed now. If you see any other deprecation warnings from
BindBC bindings you can silence them with
al\dub\packages\bindbc-glfw-1.0.1\bindbc-glfw\source\bindbc\glfw\binddynamic.d(557,11):
Deprecation: variable `bindbc.loader.system.bindWindows` is deprecated
So now what? I'm pretty sure deprecation means to replace with
something better
but what would that be? I looked on github code
dbc-glfw-1.0.1\bindbc-glfw\source\bindbc\glfw\binddynamic.d(557,11):
Deprecation: variable `bindbc.loader.system.bindWindows` is deprecated
So now what? I'm pretty sure deprecation means to replace with
something better
but what would that be? I looked on github code in binddynamic.d at
lin
\bindbc\glfw\binddynamic.d(557,11):
Deprecation: variable `bindbc.loader.system.bindWindows` is deprecated
So now what? I'm pretty sure deprecation means to replace with
something better
but what would that be? I looked on github code in
binddynamic.d at line 557 and
the package info at the DUB web site and I'm still clueless.
When I get Deprecation warning from template, I can not find the
root cause of the problem.
```sh
Deprecation: argument `_param_1` for format specification `"%d"`
must be `int`, not `ulong`
```
Is there a options to turn the Deprecation warning into assert
error, so I ca
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer
wrote:
[snip]
The feature is deprecated in its current form. The issue as I
understand it (i.e. very little) is that compilers other than
DMD could not use this same way to implement dual contexts, and
so they could not have the feat
deprecated features [1],
I'm not seeing which one this is referring to. Is it a valid
deprecation?
I could only find this [2] reference to dual-contexts, which
suggests that the problem relates to passing aliases into
member functions. Moving it to a member function fixes the
problem. Alter
ing to. Is it a valid deprecation?
I could only find this [2] reference to dual-contexts, which suggests
that the problem relates to passing aliases into member functions.
Moving it to a member function fixes the problem. Alternately, I could
make the alias part of Foo's type. My use case
On Monday, 17 May 2021 at 13:51:32 UTC, Paul Backus wrote:
[snip]
See this issue for context:
https://issues.dlang.org/show_bug.cgi?id=5710
Thanks. Lots of details there that I don't follow all of.
I mentioned in the deprecation PR [1] that it was not listed in
the list of depre
ich one this is referring to. Is it a valid
deprecation?
See this issue for context:
https://issues.dlang.org/show_bug.cgi?id=5710
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which is
deprecated".
However when I look at the list of deprecated features [1], I'm
not seeing which one this is referring to. Is it a valid
deprecation?
just have to wait until it is removed
upstream. (deprecation are not errors, so you can ignore them).
So yeah, next release.
https://github.com/dlang/phobos/commit/36c309fc5fb5bc886e14bd8010e1375fa3a57d53#diff-81bed7f05cbd4e992067b7019125e6a1349ebe5098c6980b64bbbca8d5491e17
Thank you. I am
On 03/04/2021 10:58 PM, rikki cattermole wrote:
Nullable has an alias this which has been deprecated.
It is due for removal (the alias this).
You can remove it manually from your copy of phobos source.
Otherwise you'll just have to wait until it is removed upstream.
(deprecation ar
Nullable has an alias this which has been deprecated.
It is due for removal (the alias this).
You can remove it manually from your copy of phobos source.
Otherwise you'll just have to wait until it is removed upstream.
(deprecation are not errors, so you can ignore them).
I am using the OpenMPI binding and, in recent times, I have been
getting a deprecation message when compiling. It seems to be
related to assigning Nullable!int entries to an associative
array. The following program shows the same message three times
but it does run as I expect.
import
On Wednesday, 30 September 2020 at 18:18:48 UTC, Basile B. wrote:
On Tuesday, 29 September 2020 at 17:08:40 UTC, Frak wrote:
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function
`std.typecons.Nullable!long.Nullable.get_` is depre
On Tuesday, 29 September 2020 at 17:08:40 UTC, Frak wrote:
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function
`std.typecons.Nullable!long.Nullable.get_` is deprecated -
Implicit conversion with `alias Nullable.get this` will be
re
On Wednesday, 30 September 2020 at 09:42:40 UTC, Stefan Koch
wrote:
On Wednesday, 30 September 2020 at 08:33:58 UTC, Frak wrote:
On Tuesday, 29 September 2020 at 18:25:03 UTC, Steven
Schveighoffer wrote:
On 9/29/20 1:08 PM, Frak wrote:
[...]
Because it's probably coming from a constraint, yo
On Wednesday, 30 September 2020 at 08:33:58 UTC, Frak wrote:
On Tuesday, 29 September 2020 at 18:25:03 UTC, Steven
Schveighoffer wrote:
On 9/29/20 1:08 PM, Frak wrote:
[...]
Because it's probably coming from a constraint, you probably
can't figure out the exact usage. What's more annoying is
On Tuesday, 29 September 2020 at 18:25:03 UTC, Steven
Schveighoffer wrote:
On 9/29/20 1:08 PM, Frak wrote:
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function
`std.typecons.Nullable!long.Nullable.get_` is deprecated -
Imp
On 9/29/20 10:08 AM, Frak wrote:
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is
deprecated - Implicit conversion with `alias Nullable.get this` will be
removed after 2.096. Pleas
On 9/29/20 1:08 PM, Frak wrote:
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is
deprecated - Implicit conversion with `alias Nullable.get this` will be
removed after 2.096. Pleas
Hi folks,
I've this:
/Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711):
Deprecation: function `std.typecons.Nullable!long.Nullable.get_`
is deprecated - Implicit conversion with `alias Nullable.get
this` will be removed after 2.096. Please use `.get` explicitly.
I'm
On Thursday, 30 January 2020 at 13:05:05 UTC, drug wrote:
That's probably triggered by some constraints. I had the issue
like this with Nullable:
https://github.com/dlang/phobos/pull/7324
The core problem here stems from the fact that templates are
always instantiated in the scope of the temp
On 1/30/20 2:50 PM, Martin Tschierschke wrote:
When building my small vibe.d app I am getting this messages twice:
/usr/include/dmd/phobos/std/range/primitives.d(174,38): Deprecation:
alias byKeyValue this is deprecated - Iterate over .byKeyValue instead.
/usr/include/dmd/phobos/std/range
When building my small vibe.d app I am getting this messages
twice:
/usr/include/dmd/phobos/std/range/primitives.d(174,38):
Deprecation: alias byKeyValue this is deprecated - Iterate over
.byKeyValue instead.
/usr/include/dmd/phobos/std/range/primitives.d(176,27):
Deprecation: alias
Many thanks H. S. Teoh! It works!
On Tue, Dec 24, 2019 at 12:33:34AM +, psyscout via Digitalmars-d-learn
wrote:
[...]
> auto putObjectRequest(string bucket, string key, string file)
> {
> import std.stdio : File;
>
> enum chunk_size = 16 * 1024; // 16 KiB
> auto file_ = File(file, "r");
>
> return Put
Hi all,
I'm trying to resolve a Deprecation message. File.ByChunkImpl is
private which cause a compiler message.
Any clue how to to deal with this?
(Deprecation: std.stdio.File.ByChunkImpl is not visible)
struct PutObjectRequest(Range)
if (isInputRange!Range && is(Elem
it triggers deprecation
warnings when I am actively trying to avoid them.
This code seems to work for classes too and even with DMD "-de"
compiler switch.
template isMemberDeprecated(T, string name)
{
enum isMemberDeprecated = mixin(q{__traits(isDeprecated, },
T, &q
On 9/25/19 11:35 PM, Boris Carvajal wrote:
On Wednesday, 25 September 2019 at 14:20:00 UTC, Anonymouse wrote:
I added some deprecations in my project and am going through my
templates trying to silence the warnings that suddenly popped up. This
template works, but it triggers deprecation
On Wednesday, 25 September 2019 at 14:20:00 UTC, Anonymouse wrote:
I added some deprecations in my project and am going through my
templates trying to silence the warnings that suddenly popped
up. This template works, but it triggers deprecation warnings
when I am actively trying to avoid them
On Wednesday, 25 September 2019 at 05:57:19 UTC, Tobias Pankrath
wrote:
Does your code work or does it not? I don't seem to unterstand
neither what the question here is nor what the desired result
is. Is the problem that the static reflections triggers the
deprecation warning?
I added
r, T, name)))
{
maxLength = max(maxLength, name.length);
}
}
return maxLength;
}();
}
static assert (longestMemberLength!Foo == "bbb".length);
onlineapp.d(23): Deprecation: variable `onlineapp.Foo.` is
deprecated - Use s
Is there an
ame.length);
}
}
return maxLength;
}();
}
static assert (longestMemberLength!Foo == "bbb".length);
onlineapp.d(23): Deprecation: variable `onlineapp.Foo.` is
deprecated - Use s
Is there any way to inspect the deprecated-ness of a member this
way? I onl
On 2019-09-17 22:55, Johan Engelen wrote:
Wow. How come this is not caught by the CI testing?
That issue seems to be because "writeln" is printing "type", which is an
enum. For enums, "writeln" prints the actual name of the enum member and
not the value. It seems it extracts the names of all
On 9/18/19 11:09 AM, H. S. Teoh wrote:
On Wed, Sep 18, 2019 at 10:48:27AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 9/17/19 8:14 PM, Jonathan M Davis wrote:
[...]
I suspect that deprecation messages are being triggered simply by
code trying to use Nullable in template
On Wed, Sep 18, 2019 at 10:48:27AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 9/17/19 8:14 PM, Jonathan M Davis wrote:
[...]
> > I suspect that deprecation messages are being triggered simply by
> > code trying to use Nullable in template constraints rather tha
is to special case Nullable for so many
functions, but what other alternative is there?
-Steve
Nullable isn't alone, std.json.JSONType causes a literal wall of text of
deprecation warnings.
import std.stdio;
import std.json;
void main()
{
writeln(JSONValue.init.type);
}
https://run.d
se Nullable for so many
> >> functions, but what other alternative is there?
> >>
> >> -Steve
> >
> > Nullable isn't alone, std.json.JSONType causes a literal wall of text of
> > deprecation warnings.
> >
> > import std.stdio;
&g
etup to detect deprecations and flag them as failures?
>
> It's either that, or many cases are not tested because Phobos has a lot
> of templates, not all of which are instantiated with the specific
> combination of template arguments that triggers deprecation messages.
Yes. Seb
a lot
of templates, not all of which are instantiated with the specific
combination of template arguments that triggers deprecation messages.
T
--
Without outlines, life would be pointless.
On 9/17/19 3:31 PM, Steven Schveighoffer wrote:
Hi,
I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores
of deprecation messages. One thing I've realized is that most of these
messages are generated by calls outside my code. These deprecation
messages are intend
27;t alone, std.json.JSONType causes a literal wall
of text of deprecation warnings.
import std.stdio;
import std.json;
void main()
{
writeln(JSONValue.init.type);
}
https://run.dlang.io/is/J0UDay
Wow. How come this is not caught by the CI testing?
-Johan
a literal wall of text of
deprecation warnings.
import std.stdio;
import std.json;
void main()
{
writeln(JSONValue.init.type);
}
https://run.dlang.io/is/J0UDay
I mean, I'm OK with the idea, but having these deprecation messages is
helping nobody. I can't figure out if t
On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven
Schveighoffer wrote:
I'd hate to say the answer is to special case Nullable for so
many functions, but what other alternative is there?
-Steve
Nullable isn't alone, std.json.JSONType causes a literal wall of
text of deprecatio
Hi,
I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores
of deprecation messages. One thing I've realized is that most of these
messages are generated by calls outside my code. These deprecation
messages are intended to tell you where you are calling them,
On 1/18/19 5:53 PM, Ali wrote:
Hello. I am having an issue with the code below. the out put after
compiling is this :
Deprecation: foreach: loop index implicitly converted from size_t to uint
the code is :
auto available = new int[cast(uint) max - min];
foreach (uint i, ref a
On Fri, 18 Jan 2019 22:53:23 +, Ali wrote:
> Hello. I am having an issue with the code below. the out put after
> compiling is this :
>
> Deprecation: foreach: loop index implicitly converted from size_t to
> uint
>
> the code is :
>
> auto available = n
On Fri, Jan 18, 2019 at 10:53:23PM +, Ali via Digitalmars-d-learn wrote:
> Hello. I am having an issue with the code below. the out put after
> compiling is this :
>
> Deprecation: foreach: loop index implicitly converted from size_t to
> uint
>
> the code is :
>
&g
Hello. I am having an issue with the code below. the out put
after compiling is this :
Deprecation: foreach: loop index implicitly converted from size_t
to uint
the code is :
auto available = new int[cast(uint) max - min];
foreach (uint i, ref a; available
On Friday, January 18, 2019 8:34:22 AM MST Michael via Digitalmars-d-learn
wrote:
> On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote:
> > On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
> >> This, to be, looks like quite the explicit conversion, no?
> >
> > Yeah, I agree.
On Friday, 18 January 2019 at 13:29:29 UTC, Adam D. Ruppe wrote:
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
This, to be, looks like quite the explicit conversion, no?
Yeah, I agree. But the language is silly. I just leave the type
out of foreach and explicitly cast it inside t
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
This, to be, looks like quite the explicit conversion, no?
Yeah, I agree. But the language is silly. I just leave the type
out of foreach and explicitly cast it inside the body.
On Friday, 18 January 2019 at 12:27:17 UTC, Michael wrote:
Hello all,
I am getting this deprecation warning when compiling using
DMD64 D Compiler v2.084.0 on Linux. I'm a little unsure what
the problem is, however, because the code producing these
warnings tends to be of the form:
fo
On 1/18/19 7:27 AM, Michael wrote:
Hello all,
I am getting this deprecation warning when compiling using DMD64 D
Compiler v2.084.0 on Linux. I'm a little unsure what the problem is,
however, because the code producing these warnings tends to be of the form:
foreach (int i, ref prop;
Hello all,
I am getting this deprecation warning when compiling using DMD64
D Compiler v2.084.0 on Linux. I'm a little unsure what the
problem is, however, because the code producing these warnings
tends to be of the form:
foreach (int i, ref prop; props)
This, to be, looks like
On Saturday, 7 April 2018 at 18:12:00 UTC, Alex wrote:
On Saturday, 7 April 2018 at 17:25:07 UTC, Vino wrote:
Hi All,
Request your help on the below Deprecation message.
import std.datetime.systime: Clock, days, SysTime;
void main (int AgeSize) {
int AgeSize = 1
auto ct2 = Clock.currTime
On Saturday, 7 April 2018 at 17:25:07 UTC, Vino wrote:
Hi All,
Request your help on the below Deprecation message.
import std.datetime.systime: Clock, days, SysTime;
void main (int AgeSize) {
int AgeSize = 1
auto ct2 = Clock.currTime(), st2 = ct2 + days(-AgeSize);
}
test.d(30): Deprecation
Hi All,
Request your help on the below Deprecation message.
import std.datetime.systime: Clock, days, SysTime;
void main (int AgeSize) {
int AgeSize = 1
auto ct2 = Clock.currTime(), st2 = ct2 + days(-AgeSize);
}
test.d(30): Deprecation: Symbol core.time.days is not visible
from module
On Saturday, 24 February 2018 at 20:07:04 UTC, kdevel wrote:
I don't get the point of the deprecation message:
--- intprom.d
import std.stdio;
void main ()
{
short s, t;
t = -s;
}
---
$ dmd intprom.d
intprom.d(6): Deprecation: integral promotion not done for -s,
use '-
On Saturday, 24 February 2018 at 22:30:09 UTC, Steven
Schveighoffer wrote:
The prime example is this:
byte b = -128;
int x = -b;
What would you expect x to be?
a) 128
b) -128
Neither nor. I would prefer the codomain of "-" be the range of
byte
and hence an exception thrown in that case.
On 2/24/18 4:42 PM, kdevel wrote:
On Saturday, 24 February 2018 at 20:17:12 UTC, Steven Schveighoffer wrote:
https://dlang.org/changelog/2.078.0.html#fix16997
My goodness! So there is currently no negation operator defined on short
and some other types?
No, that's not the case. It's simply
On Saturday, 24 February 2018 at 20:17:12 UTC, Steven
Schveighoffer wrote:
On 2/24/18 3:07 PM, kdevel wrote:
I don't get the point of the deprecation message:
--- intprom.d
import std.stdio;
void main ()
{
short s, t;
t = -s;
}
---
https://dlang.org/changelog/2.078.0.html#fix
On 2/24/18 3:07 PM, kdevel wrote:
I don't get the point of the deprecation message:
--- intprom.d
import std.stdio;
void main ()
{
short s, t;
t = -s;
}
---
https://dlang.org/changelog/2.078.0.html#fix16997
$ dmd intprom.d
intprom.d(6): Deprecation: integral promotion not don
I don't get the point of the deprecation message:
--- intprom.d
import std.stdio;
void main ()
{
short s, t;
t = -s;
}
---
$ dmd intprom.d
intprom.d(6): Deprecation: integral promotion not done for -s,
use '-transition=intpromote' switch or -cast(int)(s)
What shall I
Hi All,
In my generic code I now get this error, which requires manually
finding all -a[] array ops, but that is another matter.
$/src/druntime/import/core/internal/arrayop.d-mixin-57(57,20):
Deprecation: integral promotion not done for -_param_1[pos], use
'-transition=intpromote'
On Monday, 11 September 2017 at 08:55:21 UTC, Vino.B wrote:
On Sunday, 10 September 2017 at 23:10:20 UTC, Ali Çehreli wrote:
On 09/10/2017 09:53 AM, Vino.B wrote:
> auto coSizeDirList (string FFs, int SizeDir) {
> //alias DirSizeList = typeof(coSizeDirList());
I worked with a version of coSiz
On Sunday, 10 September 2017 at 23:10:20 UTC, Ali Çehreli wrote:
On 09/10/2017 09:53 AM, Vino.B wrote:
> auto coSizeDirList (string FFs, int SizeDir) {
> //alias DirSizeList = typeof(coSizeDirList());
I worked with a version of coSizeDirList() that did not take
any parameters. (Could be from
On 09/10/2017 09:53 AM, Vino.B wrote:
> auto coSizeDirList (string FFs, int SizeDir) {
> //alias DirSizeList = typeof(coSizeDirList());
I worked with a version of coSizeDirList() that did not take any
parameters. (Could be from an earlier post of yours.)
In this case, you can must use a comp
On Sunday, 10 September 2017 at 15:46:46 UTC, Ali Çehreli wrote:
On 09/10/2017 04:54 AM, Vino.B wrote:
> Thank you very much, as stated by you i used the auto
function and now
> i am get the output without any warnings
That's because now you're taking advantage of D's type
inference. Although
1 - 100 of 177 matches
Mail list logo
