Re: Beta 2.095.0
On 12/20/2020 5:21 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you, Martin and the Sixty-One!
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 21:59:31 UTC, Paolo Invernizzi wrote: My point is that the result without -de is [...] Which unfortunately is pretty useless in my case ... Could you point me towards the code that triggers this ?
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 18:05:30 UTC, Mathias LANG wrote:
On Thursday, 24 December 2020 at 11:38:11 UTC, Paolo Invernizzi
wrote:
The point is that the deprecation is coming from an external
library, it would be great to have the precise instantiation
point in that source code, so I was wondering if that dmd
improvement [1] should print a more detailed trace.
[1]
https://dlang.org/changelog/2.095.0.html#deprecation-context
It does print a detailed stack trace (up to the first symbol
that is not a template) if you don't use `-de`. If you use
`-de`, since the checks in Phobos are
`is(typeof(n.toString()))` or `__traits(compiles,
n.toString())`, then it just changes whether or not the code
compiles, and as a result changes the output of the program. A
trivial example:
```
import std.stdio, std.typecons;
struct Foo {
deprecated string toString() const { return "Oops"; }
}
void main () { writefln("%s", Foo.init); }
```
Will print, with v2.094.2 or before (dmd -run):
```
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
Oops
```
Not great. If you use `dmd -de -run`, you'll get:
```
Foo()
```
Notice the deprecations are gone, but so is the usage of the
`toString` method. Using DMD v2.095.0-beta.1 with `-de` should
give you the same output, but without `-de`:
```
% ~/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -run foo.d
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4420):
instantiated from here: hasToString!(Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4430):
instantiated from here: formatObject!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(1875):
instantiated from here: formatValueImpl!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(576):
instantiated from here: formatValue!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(1661):
... (1 instantiations, -v to show) ...
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(4271):
instantiated from here: writefln!(char, Foo)
foo.d(5):instantiated from here: writefln!(char, Foo)
Oops
```
So the feature works as intended, however `-de` is a dangerous
trap, as it changes what is instantiated.
Thanks Matias,
My point is that the result without -de is
---
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -i -g -debug
src/foo.d
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727):
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.
/Users/pinver/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/traits.d(3727):
Deprecation: function std.typecons.Nullable!short.Nullable.get_ is deprecated
- Implicit conversion with alias Nullable.get this will be removed after 2.096.
Please use .get explicitly.
---
Which unfortunately is pretty useless in my case ...
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 11:38:11 UTC, Paolo Invernizzi
wrote:
The point is that the deprecation is coming from an external
library, it would be great to have the precise instantiation
point in that source code, so I was wondering if that dmd
improvement [1] should print a more detailed trace.
[1] https://dlang.org/changelog/2.095.0.html#deprecation-context
It does print a detailed stack trace (up to the first symbol that
is not a template) if you don't use `-de`. If you use `-de`,
since the checks in Phobos are `is(typeof(n.toString()))` or
`__traits(compiles, n.toString())`, then it just changes whether
or not the code compiles, and as a result changes the output of
the program. A trivial example:
```
import std.stdio, std.typecons;
struct Foo {
deprecated string toString() const { return "Oops"; }
}
void main () { writefln("%s", Foo.init); }
```
Will print, with v2.094.2 or before (dmd -run):
```
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
Oops
```
Not great. If you use `dmd -de -run`, you'll get:
```
Foo()
```
Notice the deprecations are gone, but so is the usage of the
`toString` method. Using DMD v2.095.0-beta.1 with `-de` should
give you the same output, but without `-de`:
```
% ~/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -run foo.d
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4420):
instantiated from here: hasToString!(Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4430):
instantiated from here: formatObject!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(1875):
instantiated from here: formatValueImpl!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(576):
instantiated from here: formatValue!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(1661):
... (1 instantiations, -v to show) ...
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(4271):
instantiated from here: writefln!(char, Foo)
foo.d(5):instantiated from here: writefln!(char, Foo)
Oops
```
So the feature works as intended, however `-de` is a dangerous
trap, as it changes what is instantiated.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote: On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D. Big difference between bad decision and mockery. It's very possible he was wrong, but I don't think he wasn't taking it seriously.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 15:00:16 UTC, jmh530 wrote:
That Foo-ish reminds me of something in D like
static if (__traits(compiles, {
auto temp = Foo!T.init;
}))
Yes, it is similar in spirit. It is pretty much the same as the
C++17 version, but easier to write, especially when you require
many operators (e.g. "a+b", "a*b" etc). I am not sure if C++20
concepts bring anything truly new, but easier on the eyes and
more likely to be used correctly. Which is important. A new
feature isn't necessarily about making new things possible,
encouraging correct code is just as important.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 09:56:50 UTC, Ola Fosheim
Grøstad wrote:
[snip]
I don't use concepts yet as it is a very new C++ feature. The
following code does not work in XCode, although it probably
should according to cppreference. So take this with a grain of
salt (other variations should be possible):
namespace detail {
template typename F, class U>
constexpr void _is_instantiable(F a){}
}
template
struct Foo{};
template
concept Fooish = requires(T a){
detail::_is_instantiable(a);
};
That Foo-ish reminds me of something in D like
static if (__traits(compiles, {
auto temp = Foo!T.init;
}))
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D.
Re: Printing shortest decimal form of floating point number with Mir
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 11:05:16 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
[...]
Non-concept version is more verbose, but yeah, works fine in
C++17:
namespace detail {
template class F, class U>
static constexpr void _dummy(const F );
template typename F, class=void>
struct has_outer_template : std::false_type {};
template typename F>
struct
has_outer_template(std::declval()))>>: std::true_type {};
};
template typename F>
inline constexpr bool has_outer_template =
detail::has_outer_template::value;
template
struct Foo{};
static_assert(has_outer_template,Foo>);
Thank you for the examples. They make sense.
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 11:05:14 UTC, Mathias LANG wrote: On Wednesday, 23 December 2020 at 15:38:17 UTC, Steven Schveighoffer wrote: What is happening is that some speculative compilation is checking something via the get function. It might not make a difference, but the error message is useless (who knows where that traits call is triggered). FYI, v2.095.0 *should* print the instantiation trace, so you can actually track down where it comes from. And the reason DMD now shows the trace is exactly because of this deprecation. The point is that the deprecation is coming from an external library, it would be great to have the precise instantiation point in that source code, so I was wondering if that dmd improvement [1] should print a more detailed trace. [1] https://dlang.org/changelog/2.095.0.html#deprecation-context
Re: Printing shortest decimal form of floating point number with Mir
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
concept Bar(T) = requires(U)() {
Foo!U; //akin to something like typename T::Foo;
}
where we would basically be telling the compiler that T has to
be a Foo!U, which would mean you would have to use Bar like
Bar!U...at least that's the idea. I don't think anything like
this would work currently in C++.
Non-concept version is more verbose, but yeah, works fine in
C++17:
namespace detail {
template class F, class U>
static constexpr void _dummy(const F );
template typename F, class=void>
struct has_outer_template : std::false_type {};
template typename F>
struct
has_outer_template(std::declval()))>>: std::true_type {};
};
template typename F>
inline constexpr bool has_outer_template =
detail::has_outer_template::value;
template
struct Foo{};
static_assert(has_outer_template,Foo>);
Re: Beta 2.095.0
On Wednesday, 23 December 2020 at 15:38:17 UTC, Steven Schveighoffer wrote: What is happening is that some speculative compilation is checking something via the get function. It might not make a difference, but the error message is useless (who knows where that traits call is triggered). FYI, v2.095.0 *should* print the instantiation trace, so you can actually track down where it comes from. And the reason DMD now shows the trace is exactly because of this deprecation. Most likely, it doesn't change anything. Therefore when you turn on the deprecation as an error, it doesn't affect compilation, it just fails in the speculation instead of succeeds. But the ultimate result doesn't actually change anything. I can't wait until this deprecation has been finalized, because I hate seeing seas of deprecation messages I can't do anything about. 2.097 cannot come soon enough... FYI, in theory we could use `__traits(isDeprecated)` to silence this. But I haven't looked at the code myself.
Re: Printing shortest decimal form of floating point number with Mir
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
doing similar things). Abusing C++'s syntax you might have
something like
concept Bar(T) = requires(U)() {
Foo!U; //akin to something like typename T::Foo;
}
where we would basically be telling the compiler that T has to
be a Foo!U, which would mean you would have to use Bar like
Bar!U...at least that's the idea. I don't think anything like
this would work currently in C++.
I don't use concepts yet as it is a very new C++ feature. The
following code does not work in XCode, although it probably
should according to cppreference. So take this with a grain of
salt (other variations should be possible):
namespace detail {
template typename F, class U>
constexpr void _is_instantiable(F a){}
}
template
struct Foo{};
template
concept Fooish = requires(T a){
detail::_is_instantiable(a);
};
