Deprecation
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) a = min + i; Any help would be highly appreciated.
Deprecation
> Deprecation: super is not an lvalue 1) How to know when this will indeed be deprecated? 2) What does it mean, when `super++' is signalled as depracation, but `super+=' is not signalled? -manfred
Re: Deprecation
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 : > > auto available = new int[cast(uint) max - min]; Replace uint with size_t. > foreach (uint i, ref a; available) Ditto. > a = min + i; > > Any help would be highly appreciated. T -- Study gravitation, it's a field with a lot of potential.
Re: Deprecation
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 = new int[cast(uint) max - min]; > foreach (uint i, ref a; available) > a = min + i; > > Any help would be highly appreciated. You are trying to use a uint (max value 2^32-1) to give an index for an array (which might be more than 2^32-1 elements long). That's deprecated and will be gone from the language in a few releases. Instead, write: foreach (size_t i, ref a; available) a = cast(uint)(min + i);
Re: Deprecation
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; available) foreach (i, ref a; available) a = min + i; a = cast(uint)(min + i); Any help would be highly appreciated. -Steve
Re: Deprecation
On 5/15/15 12:50 PM, Manfred Nowak wrote: Deprecation: super is not an lvalue 1) How to know when this will indeed be deprecated? 2) What does it mean, when `super++' is signalled as depracation, but `super+=' is not signalled? That seems like a bug. I think super being an lvalue in this context simply means that the *reference* is not an lvalue (e.g. you can't do super = someOtherObject), not the object it points at. Clearly anything that is passed by reference is an lvalue. -Steve
Re: Deprecation
Steven Schveighoffer wrote: > That seems like a bug. https://issues.dlang.org/show_bug.cgi?id=14589 -manfred
Deprecation of toUTF16
Hi, I have some problems to find out what to use instead of the deprecated toUTF16 function. I am calling a shared library written in Delphi. While this coding is working fine (with german ü) import std.utf: toUTF16; wstring ws = toUTF16(s); BSTR bStr = SysAllocStringLen(ws.ptr, cast(UINT) ws.length); This coding fails to display the german ü correctly: import std.utf: encode; wchar[] ws; s.each!(c => encode(ws, c)); BSTR bStr = SysAllocStringLen(ws.ptr, cast(UINT) ws.length); Variable s is of type string. On delphi side WideString is used as type for the string. Where is the error? Kind regards André
testing for deprecation
How does one test whether a symbol is deprecated? I would have
expected something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not
accessible in any way from code?
The only solution I can think of is compiling with -de and using
__traits(compiles, {alias x = foo;})
which actually does seem to work. Pretty lousy though.
Deprecation process documented?
Is the deprecation process used for Phobos and druntime code documented somewhere? I.e. how long after a deprecation is a symbols removed and so on. -- /Jacob Carlborg
Deprecation in traits
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 trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions?
dual-context deprecation
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?
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 it is just a little easier structured like this, but I get
that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
[1] https://dlang.org/deprecate.html
[2]
https://forum.dlang.org/thread/mkeumwltwiimkrelg...@forum.dlang.org
Deprecation message sources
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, but end up
telling you where phobos, or vibe.d, or whatever, is calling them.
For example, I get messages like:
home/steves/.dvm/compilers/dmd-2.088.0/linux/bin/../../src/phobos/std/traits.d(3687,61):
Deprecation: function std.typecons.Nullable!string.Nullable.get_ is
deprecated - Implicit conversion with alias Nullable.get this will be
removed after 2.096. Please use .get explicitly.
The line in question is commented below:
template hasElaborateAssign(S)
{
static if (isStaticArray!S && S.length)
{
enum bool hasElaborateAssign =
hasElaborateAssign!(typeof(S.init[0]));
}
else static if (is(S == struct))
{
/* the line below /
enum hasElaborateAssign =
is(typeof(S.init.opAssign(rvalueOf!S))) ||
is(typeof(S.init.opAssign(lvalueOf!S))) ||
anySatisfy!(.hasElaborateAssign, FieldTypeTuple!S);
}
else
{
enum bool hasElaborateAssign = false;
}
}
I'm not calling hasElaborateAssign from anywhere in my code. So 1. how
am I supposed to know where this call is being generated from, and 2.
I'm assuming this is happening inside a static if buried deep somewhere
in library code, so how am I supposed to fix it?
I'd hate to say the answer is to special case Nullable for so many
functions, but what other alternative is there?
-Steve
std.stream, BOM, and deprecation
If std.stream is being deprecated, what is the correct way to deal with file BOMs. This is particularly concerning utf8 files, which I understand to be a bit problematic, as there isn't, actually, a utf8 BOM, merely a convention which isn't a part of a standard. But the std.stdio documentation doesn't so much as mention byte order marks (BOMs). If this should wait until std.io is released, then I could use std.stream until them, but the documentation is already warning to avoid using it.
Re: testing for deprecation
On Thursday, 1 September 2016 at 11:13:42 UTC, rikki cattermole
wrote:
That is a first that somebody wanted it.
Bug report please!
I just ran across this with
deprecated {
void foo();
}
void main() {
pragma(msg, __traits(getAttributes, foo));
}
producing just tuple(). I came across this when looping through
the members of a module and wanting to skip the deprecated ones.
I did a quick look in Bugzilla and didn't find anything. Do you
know if anyone filed anything I may have missed?
Re: testing for deprecation
On Friday, 25 August 2017 at 20:35:52 UTC, jmh530 wrote:
On Thursday, 1 September 2016 at 11:13:42 UTC, rikki cattermole
wrote:
That is a first that somebody wanted it.
Bug report please!
I just ran across this with
deprecated {
void foo();
}
void main() {
pragma(msg, __traits(getAttributes, foo));
}
producing just tuple().
getAttributes is made for UDAs only.
Re: testing for deprecation
On Saturday, 26 August 2017 at 07:17:49 UTC, user1234 wrote:
getAttributes is made for UDAs only.
Okay, well if you change it to
deprecated {
void foo();
}
void main() {
pragma(msg, __traits(getFunctionAttributes, foo));
}
then you just get
tuple(@system)
so the issue still stands. I see no way to loop through members
of a module at compile-time and exclude the ones that are
deprecated.
Re: testing for deprecation
On Monday, August 28, 2017 13:08:04 jmh530 via Digitalmars-d-learn wrote:
> On Saturday, 26 August 2017 at 07:17:49 UTC, user1234 wrote:
> > getAttributes is made for UDAs only.
>
> Okay, well if you change it to
>
> deprecated {
> void foo();
> }
>
> void main() {
> pragma(msg, __traits(getFunctionAttributes, foo));
> }
>
> then you just get
>
> tuple(@system)
>
> so the issue still stands. I see no way to loop through members
> of a module at compile-time and exclude the ones that are
> deprecated.
I think that it's pretty clear that a new traits for __traits would be
required. Per the documentation, getFunctionAttributes does not include
anything about deprecation, and even if it did, it wouldn't be sufficient
anyway, because it would only cover functions, whereas almost any symbol
that isn't local to a function can be deprecated (the only case I can think
of at the moment where you can't deprecate a symbol that isn't inside a
function is enum members, which can't be individually deprecated, because
you can't apply any attributes to them individually). We'd probably need
something like __traits(isDeprecated, symbol).
https://issues.dlang.org/show_bug.cgi?id=17791
- Jonathan M Davis
Re: testing for deprecation
On Monday, 28 August 2017 at 21:29:31 UTC, Jonathan M Davis wrote: I think that it's pretty clear that a new traits for __traits would be required. Per the documentation, getFunctionAttributes does not include anything about deprecation, and even if it did, it wouldn't be sufficient anyway, because it would only cover functions, whereas almost any symbol that isn't local to a function can be deprecated (the only case I can think of at the moment where you can't deprecate a symbol that isn't inside a function is enum members, which can't be individually deprecated, because you can't apply any attributes to them individually). We'd probably need something like __traits(isDeprecated, symbol). https://issues.dlang.org/show_bug.cgi?id=17791 - Jonathan M Davis Thanks for filing that!
Re: testing for deprecation
On Thursday, 1 September 2016 at 11:11:15 UTC, Cauterite wrote: How does one test whether a symbol is deprecated? I would have expected something like: __traits(isDeprecated, foo). Such a trait makes it possible to write code that will break, just because something has been marked as deprecated. Doesn't it break the purpose of deprecation?
Re: testing for deprecation
On Tuesday, 29 August 2017 at 05:03:39 UTC, Sebastien Alaiwan wrote: On Thursday, 1 September 2016 at 11:11:15 UTC, Cauterite wrote: How does one test whether a symbol is deprecated? I would have expected something like: __traits(isDeprecated, foo). Such a trait makes it possible to write code that will break, just because something has been marked as deprecated. Doesn't it break the purpose of deprecation? Yeah. static assert (!__traits(isDeprecated, foo), "i could use the -de switch as well"); I don't see any real-world usage for this trait. That being said the amount of work to implement this in the compiler is trivial. I would tear down the feature + its tests in half an hour i think.
Re: Deprecation of toUTF16
import std.conv; auto ws=s.to!wstring;
Re: Deprecation of toUTF16
On Thursday, 31 August 2017 at 17:22:51 UTC, Kagamin wrote: import std.conv; auto ws=s.to!wstring; Thank you! Kind regards André
Re: Deprecation of toUTF16
On 8/31/17 12:12 PM, Andre Pany wrote: Hi, I have some problems to find out what to use instead of the deprecated toUTF16 function. I am calling a shared library written in Delphi. While this coding is working fine (with german ü) import std.utf: toUTF16; wstring ws = toUTF16(s); BSTR bStr = SysAllocStringLen(ws.ptr, cast(UINT) ws.length); This coding fails to display the german ü correctly: import std.utf: encode; wchar[] ws; s.each!(c => encode(ws, c)); BSTR bStr = SysAllocStringLen(ws.ptr, cast(UINT) ws.length); Variable s is of type string. On delphi side WideString is used as type for the string. Where is the error? The error is actually in the compiler -- the toUTF16 function you are calling is NOT being deprecated. But the compiler mistakenly is marking it as deprecated. See here: https://issues.dlang.org/show_bug.cgi?id=17193 -Steve
deprecation warning after upgrade
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' switch or -cast(int)(_param_1[pos]) Is there a way to avoid this in generic code so I can still take advantage of array ops? E.g. this.vec[] = -this.vec[]; Or do I have to do some wrangling like this? this.vec = this.vec.map!(a => -cast(int)(a)).array.to!(T[]) ?? What would be a good idiomatic way to fix this deprecation issue? I do not want to use the flag but make my code better, not mask the issue. Thanks, Norm
std.datetime.systime: days Deprecation message
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 test.d because it is privately imported in module
systime
From,
Vino.B
Re: testing for deprecation
On 01/09/2016 11:11 PM, Cauterite wrote:
How does one test whether a symbol is deprecated? I would have expected
something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not accessible in
any way from code?
The only solution I can think of is compiling with -de and using
__traits(compiles, {alias x = foo;})
which actually does seem to work. Pretty lousy though.
That is a first that somebody wanted it.
Bug report please!
Re: Deprecation process documented?
On Tuesday, February 24, 2015 08:49:55 Jacob Carlborg via Digitalmars-d-learn wrote: > Is the deprecation process used for Phobos and druntime code documented > somewhere? I.e. how long after a deprecation is a symbols removed and so on. No, it's not documented. I really should put it up on the wiki. The current process is that if the replacement for the symbol is being introduced at the same time, the old symbol will be marked as deprecated for a release (so that it's possible for code to build on both the latest release and on master without getting deprecation messages with either). If there is no replacement, or the replacement already exists, then that's not necessary. After that, the symbol is deprecated but documented for about a year. Then it's undocumented but remains there and deprecated for about another year, and then it finally gets removed entirely. Release dates tend to screw with how consistent the timing is (since the release dates generally haven't been consistent or even necessarily frequent), and sometimes we adjust it depending on the particular circumstances of a symbol. And of course, we've been trying to deprecate stuff rarely for a while now, so there isn't much going through the deprecation process at the moment. But that's approximately what we've been doing with the deprecation process for a while now. If anything sits in a particular stage of the deprecation cycle for longer than that, it's typically either because I didn't get around to moving it along when I was supposed to or because someone else deprecated it and didn't mark it the way that I normally mark them, in which case, I sometimes miss those. - Jonathan M Davis
Re: Deprecation process documented?
On Tuesday, 24 February 2015 at 07:49:55 UTC, Jacob Carlborg wrote: Can you help me about 'Concurrency in D'? Thank you. http://forum.dlang.org/thread/dugsyhsswoovgywpl...@forum.dlang.org Some people think rust is better ,but I think D is better. But I don't know that how to use 'Concurrency in D',Can you help me ? Thank you.
Re: Deprecation process documented?
On 2015-02-24 10:20, Jonathan M Davis via Digitalmars-d-learn wrote: No, it's not documented. I really should put it up on the wiki. The current process is that if the replacement for the symbol is being introduced at the same time, the old symbol will be marked as deprecated for a release (so that it's possible for code to build on both the latest release and on master without getting deprecation messages with either). If there is no replacement, or the replacement already exists, then that's not necessary. After that, the symbol is deprecated but documented for about a year. Then it's undocumented but remains there and deprecated for about another year, and then it finally gets removed entirely. Is the symbol deprecated right away or is there some kind of "scheduled for deprecation " in the documentation? Release dates tend to screw with how consistent the timing is (since the release dates generally haven't been consistent or even necessarily frequent), and sometimes we adjust it depending on the particular circumstances of a symbol. And of course, we've been trying to deprecate stuff rarely for a while now, so there isn't much going through the deprecation process at the moment. But that's approximately what we've been doing with the deprecation process for a while now. If anything sits in a particular stage of the deprecation cycle for longer than that, it's typically either because I didn't get around to moving it along when I was supposed to or because someone else deprecated it and didn't mark it the way that I normally mark them, in which case, I sometimes miss those. Ok, thanks. -- /Jacob Carlborg
Re: Deprecation process documented?
On Tuesday, February 24, 2015 17:57:12 Jacob Carlborg via Digitalmars-d-learn wrote: > On 2015-02-24 10:20, Jonathan M Davis via Digitalmars-d-learn wrote: > > > No, it's not documented. I really should put it up on the wiki. The current > > process is that if the replacement for the symbol is being introduced at the > > same time, the old symbol will be marked as deprecated for a release (so > > that it's possible for code to build on both the latest release and on > > master without getting deprecation messages with either). If there is no > > replacement, or the replacement already exists, then that's not necessary. > > After that, the symbol is deprecated but documented for about a year. Then > > it's undocumented but remains there and deprecated for about another year, > > and then it finally gets removed entirely. > > Is the symbol deprecated right away or is there some kind of "scheduled > for deprecation " in the documentation? Normally, the symbol is deprecated right away, because using a deprecated symbol just results in a message being printing, but if a new symbol is being introduced to replace the deprecated one at the same time that the old symbol is deprecated, then we'll mark it as "scheduled for deprecation" in the docs so that a project has a way to be built with both the latest release and master without getting an deprecation messages. Previously, we hadn't been doing that, but it caused Vladmir some problems when a symbol that he was using in dfeed (or some other similar project) was in a template and ended up flooding his console with deprecation messages, and he needed to be able to build with both the latest release and with master. So, the process was adjusted to take that into account. Regardless, when a symbol is either marked as "scheduled for deprecation" in the docs or outright deprecated, a date is usually put in the docs for when it will be moved to the next deprecation stage, though in the case of "scheduled for deprecation," there's a decent chance that it'll be marked with the next release number rather than a date, since the idea there is to give folks a release of leeway so that they can avoid deprecation messages when building with master rather than give them a particular period of time to change their code before the symbol goes away, as is the case with symbols that are actually deprecated. - Jonathan M Davis
Re: Deprecation process documented?
On Tue, Feb 24, 2015 at 09:55:28AM -0800, Jonathan M Davis via Digitalmars-d-learn wrote: [...] > Regardless, when a symbol is either marked as "scheduled for > deprecation" in the docs or outright deprecated, a date is usually put > in the docs for when it will be moved to the next deprecation stage, > though in the case of "scheduled for deprecation," there's a decent > chance that it'll be marked with the next release number rather than a > date, since the idea there is to give folks a release of leeway so > that they can avoid deprecation messages when building with master > rather than give them a particular period of time to change their code > before the symbol goes away, as is the case with symbols that are > actually deprecated. [...] What about Walter's recent complaint that certain old symbols have gone away and no upgrade path was presented to the user, just an inscrutible error message? I thought the consensus from that discussion was to leave deprecated symbols undocumented but still defined (even if it's just a no-op stub with a deprecation message or static assert pointing the user to the new symbol(s)). T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Re: Deprecation process documented?
On Tuesday, February 24, 2015 10:05:21 H. S. Teoh via Digitalmars-d-learn wrote: > On Tue, Feb 24, 2015 at 09:55:28AM -0800, Jonathan M Davis via > Digitalmars-d-learn wrote: > [...] > > Regardless, when a symbol is either marked as "scheduled for > > deprecation" in the docs or outright deprecated, a date is usually put > > in the docs for when it will be moved to the next deprecation stage, > > though in the case of "scheduled for deprecation," there's a decent > > chance that it'll be marked with the next release number rather than a > > date, since the idea there is to give folks a release of leeway so > > that they can avoid deprecation messages when building with master > > rather than give them a particular period of time to change their code > > before the symbol goes away, as is the case with symbols that are > > actually deprecated. > [...] > > What about Walter's recent complaint that certain old symbols have gone > away and no upgrade path was presented to the user, just an inscrutible > error message? I thought the consensus from that discussion was to leave > deprecated symbols undocumented but still defined (even if it's just a > no-op stub with a deprecation message or static assert pointing the user > to the new symbol(s)). There was some discussion of that, though I don't know that a consensus was reached. I don't remember all of the details of that discussion though. However, I do tend to be very much in favor of _not_ leaving cruft around like that long term, so that may color what I'm remembering. However, the problem that Walter ran into was because he waited over two years before updating his code, and trying an intermediate release of the compiler and std lib would have taken care of the problem. - Jonathan M Davis
Re: Deprecation process documented?
On 2015-02-24 18:55, Jonathan M Davis via Digitalmars-d-learn wrote: Normally, the symbol is deprecated right away, because using a deprecated symbol just results in a message being printing, but if a new symbol is being introduced to replace the deprecated one at the same time that the old symbol is deprecated, then we'll mark it as "scheduled for deprecation" in the docs so that a project has a way to be built with both the latest release and master without getting an deprecation messages. Previously, we hadn't been doing that, but it caused Vladmir some problems when a symbol that he was using in dfeed (or some other similar project) was in a template and ended up flooding his console with deprecation messages, and he needed to be able to build with both the latest release and with master. So, the process was adjusted to take that into account. Regardless, when a symbol is either marked as "scheduled for deprecation" in the docs or outright deprecated, a date is usually put in the docs for when it will be moved to the next deprecation stage, though in the case of "scheduled for deprecation," there's a decent chance that it'll be marked with the next release number rather than a date, since the idea there is to give folks a release of leeway so that they can avoid deprecation messages when building with master rather than give them a particular period of time to change their code before the symbol goes away, as is the case with symbols that are actually deprecated. Thank you for the explanation. -- /Jacob Carlborg
Re: Deprecation in traits
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. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? Because it's probably coming from a constraint, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve
Re: Deprecation in traits
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. Please use `.get` explicitly.
I'm trying to find out WHERE this is generated to fix it, dependency
included, without success.
Suggestions?
I've just ported my code to 2.094 and had to clean up that issue.
Luckily, in my case they were all in user code. I had to access my
Nullable objects with .get:
if (n) {
// n.foo();<-- from
n.get.foo(); <-- to
}
So, look at all your Nullable objects maybe.
Ali
Re: Deprecation in traits
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 - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? Because it's probably coming from a constraint, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve That's REALLY REALLY annoying! I'm spending LOT of time trying to figure out the exact point to fix in the code. Any idea? dustmite?
Re: Deprecation in traits
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 that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve That's REALLY REALLY annoying! I'm spending LOT of time trying to figure out the exact point to fix in the code. Any idea? dustmite? You can give me access to the code and I can find it out for you. That's the best I have.
Re: Deprecation in traits
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, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve That's REALLY REALLY annoying! I'm spending LOT of time trying to figure out the exact point to fix in the code. Any idea? dustmite? You can give me access to the code and I can find it out for you. That's the best I have. Thank you, but unfortunately that's not possible
Re: Deprecation in traits
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 removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? The problem has been observed already and it is an official enhancement request [1]. I think it is legit because deprecation are sometimes used to help into refactoring, so to have the use site is a essential. [1] https://issues.dlang.org/show_bug.cgi?id=21176
Re: Deprecation in traits
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 deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? The problem has been observed already and it is an official enhancement request [1]. I think it is legit because deprecation are sometimes used to help into refactoring, so to have the use site is a essential. [1] https://issues.dlang.org/show_bug.cgi?id=21176 Does compiling with -v help? I think it might at least show you which module the issue is coming from?
Re: dual-context deprecation
On Monday, 17 May 2021 at 13:47:28 UTC, jmh530 wrote: 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? See this issue for context: https://issues.dlang.org/show_bug.cgi?id=5710
Re: dual-context deprecation
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 deprecated features. [1] https://github.com/dlang/dmd/pull/9702
Re: dual-context deprecation
On 5/17/21 9:47 AM, jmh530 wrote:
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?
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 it is just a little
easier structured like this, but I get that there are workarounds.
My bigger question is about why it isn't listed more than anything.
I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
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
feature. This means that valid code in DMD would not compile on GDC or LDC.
The way forward was to deprecate the mechanism used to implement it for
DMD, and at some point tackle it in a backend-agnostic way.
Personally, I don't know why we can't fix it so that it's portable, but
I understand so little about compilers that I've pretty much stayed out
of it. The feature is very much needed.
-Steve
Re: dual-context deprecation
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 feature. This means that valid code in DMD would not compile on GDC or LDC. The way forward was to deprecate the mechanism used to implement it for DMD, and at some point tackle it in a backend-agnostic way. Personally, I don't know why we can't fix it so that it's portable, but I understand so little about compilers that I've pretty much stayed out of it. The feature is very much needed. -Steve That's a good summary. Thanks.
Re: dual-context deprecation
On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer
wrote:
On 5/17/21 9:47 AM, jmh530 wrote:
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?
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 it is just a little easier structured like
this, but I get that there are workarounds.
My bigger question is about why it isn't listed more than
anything. I.e., should I file something in bugzilla.
```d
struct Foo
{
double a;
this(double x)
{
this.a = x;
}
double b(alias inverse)()
{
return inverse(a);
}
}
void main()
{
auto foo = Foo(2.0);
auto x = foo.b!(a => (10.0 ^^ a))();
}
```
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 feature. This means that valid code
in DMD would not compile on GDC or LDC.
The way forward was to deprecate the mechanism used to
implement it for DMD, and at some point tackle it in a
backend-agnostic way.
Personally, I don't know why we can't fix it so that it's
portable, but I understand so little about compilers that I've
pretty much stayed out of it. The feature is very much needed.
-Steve
The dual context that warning is referring to is vthis2, which
the gdc maintainer struggle to implemented for the gdc compiler.
A correct fix involves templates having their own context.
-Alex
Re: Deprecation message sources
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 deprecation warnings.
import std.stdio;
import std.json;
void main()
{
writeln(JSONValue.init.type);
}
https://run.dlang.io/is/J0UDay
Re: Deprecation message sources
On 9/17/19 4:16 PM, Anonymouse wrote:
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
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 there's something I'm supposed to,
or can, change in order to get rid of them.
There are quite a few places where it is flagging my code for Nullable
usage without get, and I'm fixing those. But I'll still be left with
this mess of deprecation messages from Phobos and vibe.d. I don't even
know where or if it will break once the alias this is removed.
-Steve
Re: Deprecation message sources
On Tuesday, 17 September 2019 at 20:16:12 UTC, Anonymouse wrote:
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 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
Re: Deprecation message sources
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 intended to tell you where you are calling them, but end up
telling you where phobos, or vibe.d, or whatever, is calling them.
Bug in compiler?
void foo(int y)
{
}
void main()
{
Nullable!int x = 5;
assert(x > 0); // No deprecation warning
foo(x); // deprecation warning
}
Using -vcg-ast, it is indeed calling the _get function in both cases.
-Steve
Re: Deprecation message sources
On Tue, Sep 17, 2019 at 08:55:27PM +, Johan Engelen via Digitalmars-d-learn wrote: [...] > Wow. How come this is not caught by the CI testing? [...] Is the CI setup 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. T -- Without outlines, life would be pointless.
Re: Deprecation message sources
On Tuesday, September 17, 2019 5:28:33 PM MDT H. S. Teoh via Digitalmars-d- learn wrote: > On Tue, Sep 17, 2019 at 08:55:27PM +, Johan Engelen via > Digitalmars-d-learn wrote: [...] > > > Wow. How come this is not caught by the CI testing? > > [...] > > Is the CI setup 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 made druntime and Phobos compile with -de a while back in order to make sure that all cases where deprecations pop up actually get fixed - but of course, that's only going to catch the cases that are in the tests, and it probably wouldn't be hard to trigger a bunch of deprecations in Phobos by doing something like using a range of Nullable, since implicit conversions would probably get triggered all over the place - especially if it's the case that the deprecation message gets triggered by stuff like static if tests and template constraints (I'm not sure that it does in this case, but I have seen problems in the past where template constraints triggered deprecation messages; last time I tried to deprecate TickDuration, I ran into a bunch of problems like that, which is why it hasn't been deprecated yet). - Jonathan M Davis
Re: Deprecation message sources
On Tuesday, September 17, 2019 2:34:00 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 9/17/19 4:16 PM, Anonymouse wrote:
> > 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
> > 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 there's something I'm supposed to,
> or can, change in order to get rid of them.
>
> There are quite a few places where it is flagging my code for Nullable
> usage without get, and I'm fixing those. But I'll still be left with
> this mess of deprecation messages from Phobos and vibe.d. I don't even
> know where or if it will break once the alias this is removed.
I ran into problems along those lines with dxml recently, and I couldn't
figure out why one of the deprecation messages was being triggered. It
seemed to have to do with isInputRange, but I couldn't figure out where in
my code was resulting in that problem. I tried to track it down by compiling
Phobos with the alias this outright removed from Nullable (with the idea
that I'd then hopefully get some decent error messages wherever the real
problem was), and dxml's tests then compiled and ran just fine with no
deprecation messages. So, I don't know what to do about it. I suspect that
deprecation messages are being triggered simply by code trying to use
Nullable in template constraints rather than just when it's actually used in
proper code, but I don't know.
I ran into problems along those lines when I last tried to deprecate
TickDuration (which is why it's not yet deprecated). Template constraints
were triggering deprecation messages when I didn't think that they should
be, but unfortunately, I didn't have time to narrow down what was going on
so that I could create a proper bug report for it, and I haven't gotten back
to it.
- Jonathan M Davis
Re: Deprecation message sources
On 9/17/19 8:14 PM, Jonathan M Davis wrote:
On Tuesday, September 17, 2019 2:34:00 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 9/17/19 4:16 PM, Anonymouse wrote:
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
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 there's something I'm supposed to,
or can, change in order to get rid of them.
There are quite a few places where it is flagging my code for Nullable
usage without get, and I'm fixing those. But I'll still be left with
this mess of deprecation messages from Phobos and vibe.d. I don't even
know where or if it will break once the alias this is removed.
I ran into problems along those lines with dxml recently, and I couldn't
figure out why one of the deprecation messages was being triggered. It
seemed to have to do with isInputRange, but I couldn't figure out where in
my code was resulting in that problem. I tried to track it down by compiling
Phobos with the alias this outright removed from Nullable (with the idea
that I'd then hopefully get some decent error messages wherever the real
problem was), and dxml's tests then compiled and ran just fine with no
deprecation messages. So, I don't know what to do about it. I suspect that
deprecation messages are being triggered simply by code trying to use
Nullable in template constraints rather than just when it's actually used in
proper code, but I don't know.
I too, think that it's really the template constraints that are causing
so much grief. Not only that, but it's impossible to find the code
that's actually triggering the usage.
Maybe the best idea then is to use a version. In other words, you
compile your code with version=nullableRequiresGet, and then it aliases
Nullable to a new type (to avoid symbol conflicts) that requires get
without the deprecation? After the deprecation, just replace the alias
with the real Nullable. Then at least you can update your code to get
rid of all the deprecation messages.
-Steve
Re: Deprecation message sources
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 than just > > when it's actually used in proper code, but I don't know. > > I too, think that it's really the template constraints that are > causing so much grief. Not only that, but it's impossible to find the > code that's actually triggering the usage. That's really annoying. Why are constraints triggering deprecation messages? Shouldn't it be actual usage that trigger them? I've also seen similar in my own projects, and it's an eyesore, esp. since it was Phobos code that was triggering the messages, not actually anything in my own code. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Re: Deprecation message sources
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 constraints rather than just when it's actually used in proper code, but I don't know. I too, think that it's really the template constraints that are causing so much grief. Not only that, but it's impossible to find the code that's actually triggering the usage. That's really annoying. Why are constraints triggering deprecation messages? Shouldn't it be actual usage that trigger them? Well, if the constraint is going to change the result when the symbol is actually removed, I'd say yes. For example: foo(int); Nullable!int x; static if(is(typeof(foo(x))) // true before removal, false after But of course, my call isn't going to be that, that's going to be buried somewhere deep in a template. I've also seen similar in my own projects, and it's an eyesore, esp. since it was Phobos code that was triggering the messages, not actually anything in my own code. Yeah, I would like to see where the deprecation is being triggered in MY code. I don't think -de will work, because then it simply changes what the is-expression returns, rather than show me the full trace of what I was trying to instantiate. Really annoying. -Steve
Re: Deprecation message sources
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 enum members and this particular enum contains deprecated members. -- /Jacob Carlborg
-preview=in deprecation warning
Can anyone help me get rid of this depreciation?
```d
struct Foo {
string foo;
string getFoo() const @safe { return foo; }
}
size_t bar(in Foo foo) @safe {
return foo.getFoo().length;
}
void main() {
Foo("hello").bar().writeln();
}
```
```sh
$ ldc2 -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
```
Re: std.stream, BOM, and deprecation
On Saturday, October 13, 2012 18:53:48 Charles Hixson wrote: > If std.stream is being deprecated, what is the correct way to deal with > file BOMs. This is particularly concerning utf8 files, which I > understand to be a bit problematic, as there isn't, actually, a utf8 > BOM, merely a convention which isn't a part of a standard. But the > std.stdio documentation doesn't so much as mention byte order marks (BOMs). > > If this should wait until std.io is released, then I could use > std.stream until them, but the documentation is already warning to avoid > using it. std.stream will be around until after std.io has been introduced, because std.io will be its replacement. As for dealing with BOMs, I don't really know anything about that, so I don't really have any suggestions. I know that it's come up before, and you can probably find some discussion on it in the archives, but for the most part, Phobos' I/O assumes UTF-8 or compatible, and if you want something else, you have to deal with it yourself. It's an area where Phobos needs improvement. You can use std.stream, but just be aware that in the long term, you'll either have to refactor your code so that it uses another solution (presumably std.io) or copy std.stream to your own stuff, because it's going to be removed from Phobos eventually. - Jonathan M Davis
Re: std.stream, BOM, and deprecation
On 10/13/2012 06:53 PM, Charles Hixson wrote: > If std.stream is being deprecated, what is the correct way to deal with > file BOMs. This is particularly concerning utf8 files, which I > understand to be a bit problematic, as there isn't, actually, a utf8 > BOM, That's correct. There is just one byte order for UTF-8. > merely a convention which isn't a part of a standard. I am not sure about that. The Unicode standard describes UTF-8 as code units following each other in the file. There can't be any confusion about their order. According to Wikipedia, the only use of BOM for UTF-8 is to identify the file as having been encoded in UTF-8: http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8 But that can't have any meaning. The file could have been encoded in any one of the multitude of code pages as well. Treating the first three bytes as BOM would be taking a chance in that case and dropping those three characters. > But the > std.stdio documentation doesn't so much as mention byte order marks (BOMs). > > If this should wait until std.io is released, then I could use > std.stream until them, but the documentation is already warning to avoid > using it. As I understand it, it is all down to convention any way. What is the meaning of the non-ASCII code 166? Only the generator of the file knows. :/ Ali
Re: std.stream, BOM, and deprecation
On Sat, 13 Oct 2012 18:53:48 -0700 Charles Hixson wrote: > If std.stream is being deprecated, what is the correct way to deal > with file BOMs. This is particularly concerning utf8 files, which I > understand to be a bit problematic, as there isn't, actually, a utf8 > BOM, merely a convention which isn't a part of a standard. But the > std.stdio documentation doesn't so much as mention byte order marks > (BOMs). > > If this should wait until std.io is released, then I could use > std.stream until them, but the documentation is already warning to > avoid using it. Personally, I think it's kind of cumbersome to deal with in Phobos, so I wrote this wrapper that I use instead, which handles everything: https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/io.d?at=master#cl-24 And then there's the utfConvert below it if you already have the data in memory instead of on disk. (Maybe I should add some range capability and make a Phobos pull request. I don't know if it'd fly though. It uses a lot of custom endian- and bom-related code since I found the existing endian/bom stuff in phobos inadequate. So that stuff would have to be accepted, and then this too, and it's usually a bit of a pain to get things approved.)
Re: std.stream, BOM, and deprecation
On Sat, 13 Oct 2012 21:53:48 -0400, Charles Hixson wrote: If std.stream is being deprecated, what is the correct way to deal with file BOMs. This is particularly concerning utf8 files, which I understand to be a bit problematic, as there isn't, actually, a utf8 BOM, merely a convention which isn't a part of a standard. But the std.stdio documentation doesn't so much as mention byte order marks (BOMs). If this should wait until std.io is released, then I could use std.stream until them, but the documentation is already warning to avoid using it. When std.io is released, it will be fully BOM-aware by default (as long as you use the purely D versions). The plan from my point of view is for std.io be be a replacement backend for std.stdio, with the C version being the default (as it must be for compatibility purposes). -Steve
Re: std.stream, BOM, and deprecation
On 10/15/2012 10:29 AM, Steven Schveighoffer wrote: On Sat, 13 Oct 2012 21:53:48 -0400, Charles Hixson wrote: If std.stream is being deprecated, what is the correct way to deal with file BOMs. This is particularly concerning utf8 files, which I understand to be a bit problematic, as there isn't, actually, a utf8 BOM, merely a convention which isn't a part of a standard. But the std.stdio documentation doesn't so much as mention byte order marks (BOMs). If this should wait until std.io is released, then I could use std.stream until them, but the documentation is already warning to avoid using it. When std.io is released, it will be fully BOM-aware by default (as long as you use the purely D versions). The plan from my point of view is for std.io be be a replacement backend for std.stdio, with the C version being the default (as it must be for compatibility purposes). -Steve That sounds good. All of the files I'm interested should have been converted to utf8 (if they weren't already), but many of them have the utf8 BOM (so they won't be confused with other non-unicode files). It sounds like std.io will handle this in a transparent fashion.
Re: std.stream, BOM, and deprecation
On 10/14/2012 10:28 PM, Nick Sabalausky wrote: On Sat, 13 Oct 2012 18:53:48 -0700 Charles Hixson wrote: If std.stream is being deprecated, what is the correct way to deal with file BOMs. This is particularly concerning utf8 files, which I understand to be a bit problematic, as there isn't, actually, a utf8 BOM, merely a convention which isn't a part of a standard. But the std.stdio documentation doesn't so much as mention byte order marks (BOMs). If this should wait until std.io is released, then I could use std.stream until them, but the documentation is already warning to avoid using it. Personally, I think it's kind of cumbersome to deal with in Phobos, so I wrote this wrapper that I use instead, which handles everything: https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/io.d?at=master#cl-24 And then there's the utfConvert below it if you already have the data in memory instead of on disk. (Maybe I should add some range capability and make a Phobos pull request. I don't know if it'd fly though. It uses a lot of custom endian- and bom-related code since I found the existing endian/bom stuff in phobos inadequate. So that stuff would have to be accepted, and then this too, and it's usually a bit of a pain to get things approved.) That wrapper looks very nice, but it's a lot more than what I need. I want to deal only with utf8 files, many of which have BOMs. I *can* handle that by detecting the BOM and dropping it. I don't need anything else. I was merely wondering what the appropriate way to approach this was now that std.stream is being documented as deprecated, but no replacement specified. It sounds like the appropriate response is to use std.stdio, and handle the BOM myself.
Re: std.datetime.systime: days Deprecation message
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: Symbol core.time.days is not visible
from module test.d because it is privately imported in module
systime
From,
Vino.B
As far as I understand it, days are located in core.time.
import core.time : days;
Re: std.datetime.systime: days Deprecation message
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(), st2 = ct2 + days(-AgeSize);
}
test.d(30): Deprecation: Symbol core.time.days is not visible
from module test.d because it is privately imported in module
systime
From,
Vino.B
As far as I understand it, days are located in core.time.
import core.time : days;
Hi Alex,
Thank you, that resolved the issue.
From,
Vino.B
Deprecation: std.stdio.File.ByChunkImpl is not visible
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(ElementType!Range == ubyte[]))
{
string bucket;
string key;
Range content;
ulong content_size;
}
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 PutObjectRequest!(File.ByChunkImpl)(bucket, key,
file_.byChunk(chunk_size), file_.size);
}
Appreciate any help!
Thanks
Deprecation: module std.stream is deprecated
Deprecation: module std.stream is deprecated - It will be removed
from Phobos in October 2016.
The std.stream module documentation doesn't give any clues as to
what an alternative might be.
I have this sort of code:
this(InputStream input)
{
int line_no = 1;
foreach (char[] line; input) {
Am I right in thinking to use std.stdio with an InputRange?
- Jason
Re: -preview=in deprecation warning
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; }
}
Re: -preview=in deprecation warning
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 @safe { return foo; }
}
Wow. Thanks.
I tried this, but rearranged the return and scope like this
```d
// doesn't work
string getFoo() scope return const @safe { return foo; }
```
```d
// works
string getFoo() return scope const @safe { return foo; }
```
visibility deprecation with last dmd compiler
I have 2 files
file abc.d:
==
module my.abc;
class Abc
{
private int x;
this() { this.x = 1; }
}
==
and xyz.d:
==
module my.xyz;
import my.abc;
class Xyz: Abc
{
this() { super(); this.x = 2; }
}
==
Compilation fails with "Deprecation: my.abc.Abc.x is not visible
from module xyz"
As I understand, the reason is
https://dlang.org/changelog/2.071.0.html#dip22
But how can I use private fields from descedant class?
Inspecting __traits(isDeprecated) and deprecation warnings
I want to write a piece of code that reflects on the names of
members of a passed struct, where some are depreacted.
https://run.dlang.io/is/P9EtRG
struct Foo
{
string s;
int ii;
bool bbb;
deprecated("Use `s`")
string ;
}
template longestMemberLength(T)
{
enum longestMemberLength = ()
{
size_t maxLength;
foreach (immutable i, immutable name;
__traits(allMembers, T))
{
static if (!__traits(isDeprecated,
__traits(getMember, 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 any way to inspect the deprecated-ness of a member this
way? I only have what __traits(allMembers) gives me.
Re: Deprecation: std.stdio.File.ByChunkImpl is not visible
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 PutObjectRequest!(File.ByChunkImpl)(bucket, key,
> file_.byChunk(chunk_size), file_.size);
Hmm, try replacing the above line with:
auto range = file_.byChunk(chunk_size);
return PutObjectRequest!(typeof(range))(bucket, key, range, file_.size);
T
--
Never step over a puddle, always step around it. Chances are that whatever made
it is still dripping.
Re: Deprecation: std.stdio.File.ByChunkImpl is not visible
Many thanks H. S. Teoh! It works!
Re: Deprecation: module std.stream is deprecated
On Saturday, November 07, 2015 12:10:05 Spacen Jasset via Digitalmars-d-learn
wrote:
> Deprecation: module std.stream is deprecated - It will be removed
> from Phobos in October 2016.
>
> The std.stream module documentation doesn't give any clues as to
> what an alternative might be.
>
> I have this sort of code:
>
> this(InputStream input)
> {
>
> int line_no = 1;
> foreach (char[] line; input) {
>
> Am I right in thinking to use std.stdio with an InputRange?
At this point, you pretty much have three options:
1. Use std.stdio.File and read it in in pieces (e.g. with byLine or
byChunk).
2. Read the whole file in at once with std.file.read or std.file.readText.
3. Use std.mmfile.MmFile to mmap the file so that the parts that you access
get read into memory, and the rest don't get loaded from disk, but you get
to operate on the whole file as if you had read it all from disk.
- Jonathan M Davis
Re: Deprecation: module std.stream is deprecated
On Saturday, 7 November 2015 at 13:30:44 UTC, Jonathan M Davis
wrote:
On Saturday, November 07, 2015 12:10:05 Spacen Jasset via
Digitalmars-d-learn wrote:
Deprecation: module std.stream is deprecated - It will be
removed from Phobos in October 2016.
The std.stream module documentation doesn't give any clues as
to what an alternative might be.
I have this sort of code:
this(InputStream input)
{
int line_no = 1;
foreach (char[] line; input) {
Am I right in thinking to use std.stdio with an InputRange?
At this point, you pretty much have three options:
1. Use std.stdio.File and read it in in pieces (e.g. with
byLine or
byChunk).
2. Read the whole file in at once with std.file.read or
std.file.readText.
3. Use std.mmfile.MmFile to mmap the file so that the parts
that you access get read into memory, and the rest don't get
loaded from disk, but you get to operate on the whole file as
if you had read it all from disk.
- Jonathan M Davis
Thanks Jonathan. I don't quite see what I want to do though.
In order to abstract the file aspect of things away, and deal
with a stream of chars that could be from a file, or some some
other source would I use a range?
what I am after is a replacement for InputStream, I don't really
want to directly use File in most places.
So far I have this, and it seems to work, but it doesn't seem
right:
this(InputRange)(InputRange input)
{
int line_no = 1;
foreach (char[] line; input.byLine()) {
...
I have a used a template, because I cannot directly use the
InputRange(char) interface as a type, and auto won't work either,
so is there another parameter type I can use, such that I can
have the concept of an abstract stream of bytes.
Re: Deprecation: module std.stream is deprecated
On Saturday, November 07, 2015 13:52:26 Spacen Jasset via Digitalmars-d-learn
wrote:
> Thanks Jonathan. I don't quite see what I want to do though.
>
> In order to abstract the file aspect of things away, and deal
> with a stream of chars that could be from a file, or some some
> other source would I use a range?
>
> what I am after is a replacement for InputStream, I don't really
> want to directly use File in most places.
>
> So far I have this, and it seems to work, but it doesn't seem
> right:
>
> this(InputRange)(InputRange input)
> {
>
> int line_no = 1;
> foreach (char[] line; input.byLine()) {
> ...
>
> I have a used a template, because I cannot directly use the
> InputRange(char) interface as a type, and auto won't work either,
> so is there another parameter type I can use, such that I can
> have the concept of an abstract stream of bytes.
If your function accepts a range, then it's pretty much a guarantee that
it's going to be templated. std.range does define interfaces for the basic
types of ranges, but almost all ranges are structs, and what range types
typically look like when you start chaining them means that you pretty much
never want to type them out (or they're Voldemort types, in which case you
_can't_ type them out). typeof can be used to get around that, but it's
still ugly. So, you're not normally going to have non-templated code
accepting a range type which could come from who-knows-where. Rather, you'd
do something like
auto myFunc(R)(R range)
if(isInputRange!R && is(ElementType!R == dchar))
{
}
in which case the function will accept any range of dchar without caring
where it came from. But it does mean that the function is templated.
If you want a range of characters from a file, you have the three options
that I listed before.
1. You can use std.stdio.File. Nothing from it will give you a range of
characters directly (rather, it's going to give you a range of lines or
chunks), but you can get a range of charaters from that. e.g.
auto file = File("myfile.txt");
auto range = file.byLineCopy(KeepTerminator.yes).joiner();
The result is a range of dchar that can be passed to any function that
accepts a range of dchar, and those functions won't care about where those
characters came from - but they will need to be templated.
Note that you'd want byLineCopy, not byLine, since you're not using it in a
for loop, and byLine reuses its buffer, which doesn't usually work very well
with anything other than a for loop.
2. You can use std.file.read or std.file.readText. e.g.
string text = std.file.readText("myfile.txt");
This will read the entire file in at once (so if you were looking for
streams, this probably isn't what you want), but you do then have a string
that you can pass to any code that accepts a string or a range of dchar
without caring about where that string came from, and it does mean that you
can avoid templating your code and just have it accept string if that's what
you'd prefer.
3. You can use std.mmfile.MmFile to mmap the file. e.g.
auto mmFile = new MmFile("foo.txt");
auto text = cast(const(char)[])mmFile[];
This will only read the file into memory as you read the memory that now
refers to it, but you have an array to process like you'd get with readText.
So, it can be used as a range of dchar (though not a string, since the data
isn't actually immutable - even though the file is opened as read-only by
default - since another process could edit the file while you're reading
it).
https://en.wikipedia.org/wiki/Mmap
Whether mmap or byLineCopy would be faster probably depends on what you're
doing, whereas readText is the easiest to use but does require that you read
the whole file in at once.
- Jonathan M Davis
Re: Deprecation: module std.stream is deprecated
On Saturday, 7 November 2015 at 13:52:29 UTC, Spacen Jasset wrote:
[...]
I have a used a template, because I cannot directly use the
InputRange(char) interface as a type, and auto won't work
either, so is there another parameter type I can use, such that
I can have the concept of an abstract stream of bytes.
With the help of a template constraint you can abstract this. It
looks like your problem is more getting the whole range since
.byLine or .byChunk don't return the full stuff. Maybe use
std.alsorithm.joiner. As you noted you can carry the iterator
without knowing the type with auto, example:
---
import std.stdio;
import std.range, std.algorithm;
void main(string[] args)
{
auto inputRange = File(__FILE__).byChunk(1024).joiner;
Foo foo = Foo(inputRange);
}
struct Foo
{
this(T)(T t)
if (isInputRange!T && is(ElementType!T == ubyte))
{
foreach(byte b; t)
{
writef("0x%.2X ", b);
if (b == 0xA) writeln;
}
}
}
---
Re: Deprecation: module std.stream is deprecated
On Sunday, 8 November 2015 at 08:21:38 UTC, BBaz wrote:
On Saturday, 7 November 2015 at 13:52:29 UTC, Spacen Jasset
wrote:
[...]
I have a used a template, because I cannot directly use the
InputRange(char) interface as a type, and auto won't work
either, so is there another parameter type I can use, such
that I can have the concept of an abstract stream of bytes.
With the help of a template constraint you can abstract this.
It looks like your problem is more getting the whole range
since .byLine or .byChunk don't return the full stuff. Maybe
use std.alsorithm.joiner. As you noted you can carry the
iterator without knowing the type with auto, example:
---
import std.stdio;
import std.range, std.algorithm;
void main(string[] args)
{
auto inputRange = File(__FILE__).byChunk(1024).joiner;
Foo foo = Foo(inputRange);
}
struct Foo
{
this(T)(T t)
if (isInputRange!T && is(ElementType!T == ubyte))
{
foreach(byte b; t)
{
writef("0x%.2X ", b);
if (b == 0xA) writeln;
}
}
}
---
or even using an auto function:
---
import std.stdio;
import std.range, std.algorithm;
void main(string[] args)
{
auto inputRange0 = inputByteRange(File(__FILE__));
Foo foo0 = Foo(inputRange0);
ubyte[] arr = [1,2,3,4,5];
auto inputRange1 = inputByteRange(arr);
Foo foo1 = Foo(inputRange1);
}
auto inputByteRange(T)(auto ref T t)
{
static if (is(T == File))
return t.byChunk(1024).joiner;
else static if (is(T == ubyte[]))
return t;
else assert(0, "unsupported inputByteRange arg");
}
struct Foo
{
this(T)(T t)
if (isInputRange!T && is(ElementType!T == ubyte)){}
}
---
Re: Deprecation: module std.stream is deprecated
On Sunday, 8 November 2015 at 08:29:30 UTC, BBaz wrote:
On Sunday, 8 November 2015 at 08:21:38 UTC, BBaz wrote:
On Saturday, 7 November 2015 at 13:52:29 UTC, Spacen Jasset
wrote:
[...]
I have a used a template, because I cannot directly use the
InputRange(char) interface as a type, and auto won't work
either, so is there another parameter type I can use, such
that I can have the concept of an abstract stream of bytes.
With the help of a template constraint you can abstract this.
It looks like your problem is more getting the whole range
since .byLine or .byChunk don't return the full stuff. Maybe
use std.alsorithm.joiner. As you noted you can carry the
iterator without knowing the type with auto, example:
---
import std.stdio;
import std.range, std.algorithm;
void main(string[] args)
{
auto inputRange = File(__FILE__).byChunk(1024).joiner;
Foo foo = Foo(inputRange);
}
struct Foo
{
this(T)(T t)
if (isInputRange!T && is(ElementType!T == ubyte))
{
foreach(byte b; t)
{
writef("0x%.2X ", b);
if (b == 0xA) writeln;
}
}
}
---
or even using an auto function:
---
import std.stdio;
import std.range, std.algorithm;
void main(string[] args)
{
auto inputRange0 = inputByteRange(File(__FILE__));
Foo foo0 = Foo(inputRange0);
ubyte[] arr = [1,2,3,4,5];
auto inputRange1 = inputByteRange(arr);
Foo foo1 = Foo(inputRange1);
}
auto inputByteRange(T)(auto ref T t)
{
static if (is(T == File))
return t.byChunk(1024).joiner;
else static if (is(T == ubyte[]))
return t;
else assert(0, "unsupported inputByteRange arg");
}
struct Foo
{
this(T)(T t)
if (isInputRange!T && is(ElementType!T == ubyte)){}
}
---
Thank you for your detailed replies, I shall try them out when I
get a moment.
I would like to *winge* and say that it doesn't appear to be
straight forward, or at least not obvious and clean to get the
concept of an abstract steam working, which is to my mind a basic
thing.
This looks the simplest solution at the moment:
auto inputRange = File(__FILE__).byChunk(1024).joiner;
Foo foo = Foo(inputRange);
But it doesn't seem efficient and strays off the conceptual path.
In other words, why chunk things up, join them back, to get a
stream? Perhaps the problem is that File is missing a .range()
function?
Re: Deprecation: module std.stream is deprecated
On Sunday, 8 November 2015 at 14:41:11 UTC, Spacen Jasset wrote: But it doesn't seem efficient and strays off the conceptual path. In other words, why chunk things up, join them back, to get a stream? `.byChunk` caches and `.joiner` hides this caching mechanism. Both operations happen under the hood "incrementally" while using the final input range because of lazy evaluation, so if your file is big, you are assured that only slices of N bytes (1024 in my example) will be loaded at once in the DRAM (unless you accumulate the whole thing later). This matches well to a "file stream concept", at least to read. But as said in Jonathan M Davis's answer you can also read the whole file in a string or a ubyte[]. Perhaps the problem is that File is missing a .range() function? Yes but this is a bit like this that phobos ranges and algorithms work. You have many independant low-level blocks with which you can compose rather than big classes that wrap everything. The whole standard library is organized around this. std.stream was not compliant with this system and this is why "they" deprecated it (at least this is how I understood this).
Re: Deprecation: module std.stream is deprecated
On Sunday, November 08, 2015 14:41:05 Spacen Jasset via Digitalmars-d-learn wrote: > This looks the simplest solution at the moment: > > >> auto inputRange = File(__FILE__).byChunk(1024).joiner; > >> Foo foo = Foo(inputRange); > > But it doesn't seem efficient and strays off the conceptual path. > In other words, why chunk things up, join them back, to get a > stream? Perhaps the problem is that File is missing a .range() > function? It's actually doing what any "stream" based solution would have to do anyway. If you're not reading the entire file in at once, then you're going to be reading it in in chunks, even if that's wrapped up in some kind of Stream class/struct. std.stdio.File exposes the basic operations and higher level stuff can be done on top of them. Maybe std.stdio.File should have some sort of function on it to just give you a range of bytes or characters, but it's pretty trivial to use joiner to get that, and it would definitely be worse to _not_ provide functions like byLine or byChunk. Chaining functions like this is an incredibly common thing to do with ranges. Range-based functions tend to be treated like building blocks rather than kitchen sinks. And most range-based functions are lazy, so something like auto range = file.byChunk(1024).joiner(); is actually efficient, and if we did have a function on std.stdio.File to just return a range of bytes or characters, it would almost certainly just be wrapping something like this, since it is efficient, and it wouldn't make sense to implement that functionality again rather than just use the functions that we already have. - Jonathan M Davis
Re: Deprecation: module std.stream is deprecated
On Tuesday, 10 November 2015 at 11:57:03 UTC, Jonathan M Davis
wrote:
...
building blocks rather than kitchen sinks. And most range-based
...
I still can't really see why byChunk and byLine are part of the
File API? Especially byLine, I'll get byChunk go for now.
I think what I am trying to say is that there doesn't need to be
a byLine, if lineSplitter could work with some range that comes
out of the File.
The problem with your example using joiner is that:
(a) it is external to the calling function, and therefore messy,
since it will have to be used everywhere.
// not ideal
printFile(f.byChunk(1000).joiner());
(b) still can't use the range to split by lines afterwards,
lineSplitter etc don't work.
void printFile(Range)(Range i)
{
foreach (l; lineSplitter(i)) {
writefln("%d\n", l);
}
}
void main()
{
File f = File("/etc/passwd");
printFile(f.byChunk(1000).joiner()); // Not work,
linesplitter needs slicing and length?
}
traits getMember gives a deprecation warning
I'm using DMD 2.071 and am getting this new deprecation error:
source/screener/lib/syntax/semantics.d(42): Deprecation:
screener.lib.virtualmachine.functions.object is not visible from
module semantics
source/screener/lib/syntax/semantics.d(42): Deprecation:
screener.lib.virtualmachine.functions.object is not visible from
module semantics
source/screener/lib/syntax/semantics.d(42): Deprecation:
screener.lib.virtualmachine.functions.screener is not visible
from module semantics
source/screener/lib/syntax/semantics.d(42): Deprecation:
screener.lib.virtualmachine.functions.screener is not visible
from module semantics
The offendding line is this :
import screener.lib.virtualmachine.functions;
alias funcModule = screener.lib.virtualmachine.functions;
bool found = false;
foreach(m; __traits(allMembers, funcModule)) {
static if ((__traits(isStaticFunction,
__traits(getMember, funcModule, m)) || __traits(isTemplate,
__traits(getMember, funcModule, m))) && __traits(getProtection,
__traits(getMember, funcModule, m)) != "private")
{
The module 'screener.lib.virtualmachine.functions' defines
'public' functions/templates. How can i fix this?
get debug information for Deprecation warning
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 can know the template caller chain ?
Re: visibility deprecation with last dmd compiler
On Wednesday, 3 May 2017 at 14:14:16 UTC, jacob wrote: But how can I use private fields from descedant class? You don't, the whole point of private is that they aren't used from outside the module. Try `protected` instead, it is similar to private, but still allows use from a subclass.
Re: Inspecting __traits(isDeprecated) and deprecation warnings
On Tuesday, 24 September 2019 at 17:01:46 UTC, Anonymouse wrote:
I want to write a piece of code that reflects on the names of
members of a passed struct, where some are depreacted.
https://run.dlang.io/is/P9EtRG
struct Foo
{
string s;
int ii;
bool bbb;
deprecated("Use `s`")
string ;
}
template longestMemberLength(T)
{
enum longestMemberLength = ()
{
size_t maxLength;
foreach (immutable i, immutable name;
__traits(allMembers, T))
{
static if (!__traits(isDeprecated,
__traits(getMember, 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 any way to inspect the deprecated-ness of a member
this way? I only have what __traits(allMembers) gives me.
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?
Re: Inspecting __traits(isDeprecated) and deprecation warnings
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 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.
getMember in _traits(isDeprecated, __traits(getMember, T, name))
causes a warning on deprecated symbols, which I wanted to avoid
with isDeprecated, but I couldn't without first calling getMember
to get the symbol to evaluate it. There's no way to combine
isDeprecated with getMember without getting a warning.
I worked around the issue by using .tupleof instead of getMember,
which breaks it for classes (.tupleof needs a `this` and
SomeClass.init can't be it) but silences warnings for structs.
https://run.dlang.io/is/TVR8Cb
import std;
void main()
{
static assert(longestMemberName!Foo == "bbb".length);
}
struct Foo
{
string s;
int ii;
bool bbb;
deprecated("Use `s`")
string ;
}
template longestMemberName(T)
if (is(T == struct))
{
enum longestMemberName = ()
{
size_t maxLength;
T thing; // need a `this`
foreach (immutable i, member; thing.tupleof)
{
static if (!__traits(isDeprecated, thing.tupleof[i])
&&
!isType!(thing.tupleof[i]))
{
enum name = __traits(identifier,
thing.tupleof[i]);
maxLength = max(maxLength, name.length);
}
}
return maxLength;
}();
}
Re: Inspecting __traits(isDeprecated) and deprecation warnings
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.
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, ".", name, q{)});
}
https://run.dlang.io/is/iQbxOC
Re: Inspecting __traits(isDeprecated) and deprecation warnings
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 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, ".",
name, q{)});
}
https://run.dlang.io/is/iQbxOC
It's really nice! Thank you.
Re: Inspecting __traits(isDeprecated) and deprecation warnings
On Wednesday, 25 September 2019 at 20:35:55 UTC, 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
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, ".", name, q{)});
}
https://run.dlang.io/is/iQbxOC
I think I can work with this, thanks!
How to fix wrong deprecation message - dmd-2.075.1
void main()
{
import std.utf : toUTF16; // Same problem with toUTF8
wstring s = toUTF16!string("abc");
}
Compilation output:
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is
deprecated - To be removed November 2017. Please use
std.utf.encode instead.
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is
deprecated - To be removed November 2017. Please use
std.utf.encode instead.
Deprecation: foo.bar is not visible from module traits
I'm reworking my code to use UDAs, and I'm running into a wall of
text of deprecation warnings when compiling.
import std.traits;
private:
struct SomeUDA {}
@SomeUDA
void foo() {}
@SomeUDA
void bar() {}
@SomeUDA
void etc() {}
public:
void main()
{
mixin("static import thisModule = " ~ __MODULE__ ~ ";");
foreach (symbol; getSymbolsByUDA!(thisModule, SomeUDA))
{
static if (isSomeFunction!symbol)
{
pragma(msg, symbol.stringof);
}
}
}
See https://wandbox.org/permlink/6Z01koyGGRxjsNWG for the output
it gives. In the real code it's unmanageably many lines.
Is there any way to get rid of these warnings except by making
everything public? Ideally I wouldn't want to copy the source of
getSymbolsByUDA into each file doing this either.
Cannot understand deprecation message recently added to Phobos
Can somebody explain the meaning of split in the error message Deprecation: function core.time.Duration.weeks is deprecated - Please use split instead. weeks was too frequently confused for total!"weeks". given by function shortDurationString() at https://github.com/nordlow/justd/blob/master/pprint.d
Deprecation message from phobos compiling a vibe.d app.
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 byKeyValue this is deprecated - Iterate over .byKeyValue instead. /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 byKeyValue this is deprecated - Iterate over .byKeyValue instead. Unfortunately I don't know what is triggering this and what to do about. The build is working, so it is more a question of elegance.
Unused mmap library comes as deprecation warning on compile
I have about 12 different separate programmes. While compiling only one of them, it gives as warning as below: /usr/include/dmd/phobos/std/mmfile.d(344): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.linux.sys.mman for non-POSIX extensions I used `grep` tool to see any of my library files or programme code have any use of this library. grep mmap -r Result is that binary files of all 12 different programmes have mmap in them. I wondered maybe a Phobos or druntime uses it. Used grep in `/usr/include/dmd` folder as well. As far as I see in the file list, unless mmap is directly imported, no other file uses it. The only thing different about that specific programme is that it uses "curl". Does anyone know why that deprecation message is seen while it is not used anywhere? Because that executable gives following error on GDB, and I am thinking that maybe that is its problem. Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x2aaab1387700 (LWP 3418)] 0x2b97df7d in poll () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) quit
Re: How to fix wrong deprecation message - dmd-2.075.1
You should open an issue on https://issues.dlang.org/
until it is fixed you can use lazy variation byChar, byWchar or byUTF:
void main()
{
import std.utf : byWchar;
import std.array : array;
wstring s = byWchar("abc").array;
}
On Wed, Aug 16, 2017 at 7:09 AM, apz28 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> void main()
> {
> import std.utf : toUTF16; // Same problem with toUTF8
>
> wstring s = toUTF16!string("abc");
> }
>
> Compilation output:
> /d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
> be removed November 2017. Please use std.utf.encode instead.
> /d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
> be removed November 2017. Please use std.utf.encode instead.
>
>
Re: How to fix wrong deprecation message - dmd-2.075.1
On 8/16/17 1:09 AM, apz28 wrote:
void main()
{
import std.utf : toUTF16; // Same problem with toUTF8
wstring s = toUTF16!string("abc");
}
Compilation output:
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated -
To be removed November 2017. Please use std.utf.encode instead.
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated -
To be removed November 2017. Please use std.utf.encode instead.
Help me out, what is the problem with the message?
-Steve
Re: How to fix wrong deprecation message - dmd-2.075.1
It should not be print? AIAIK std.utf.toUTF16 is not deprecated:
http://dlang.org/phobos/std_utf.html#toUTF16
OK this one is:https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2760
(but this one is not in doc)
but this one should not be deprecated:
https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2777
On Wed, Aug 16, 2017 at 3:02 PM, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 8/16/17 1:09 AM, apz28 wrote:
>
>> void main()
>> {
>> import std.utf : toUTF16; // Same problem with toUTF8
>>
>> wstring s = toUTF16!string("abc");
>> }
>>
>> Compilation output:
>> /d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
>> be removed November 2017. Please use std.utf.encode instead.
>> /d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
>> be removed November 2017. Please use std.utf.encode instead.
>>
>>
> Help me out, what is the problem with the message?
>
> -Steve
>
Re: How to fix wrong deprecation message - dmd-2.075.1
On 8/16/17 9:12 AM, Daniel Kozak via Digitalmars-d-learn wrote: It should not be print? AIAIK std.utf.toUTF16 is not deprecated: http://dlang.org/phobos/std_utf.html#toUTF16 OK this one is:https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2760 (but this one is not in doc) but this one should not be deprecated: https://github.com/dlang/phobos/blob/v2.075.1/std/utf.d#L2777 Hm.. that's a bug in the compiler. Only one is marked, but both are treated as deprecated. I'm wondering if just resolving the overload triggers the message. Please file an issue. -Steve
