www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - tryTo: non-throwing variant of std.conv.to

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Have anybody thought about non-throwing variants of std.conv.to 
typically named `tryTo`
similar to what Folly

https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces

does, for instance, as

     tryTo<int>(str).then([](int i) { use(i); });

?

Would it be sane to add these to std.conv alongside existing 
std.conv.to so that underlying logic in std.conv.to can be reused?

If so, AFAICT, existing std.conv.to should be implemented on top 
of std.conv.tryTo.
Aug 15 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 15 August 2018 at 09:21:29 UTC, Per Nordlöw wrote:

 Have anybody thought about non-throwing variants of std.conv.to 
 typically named `tryTo`
 similar to what Folly

 https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces

 does, for instance, as

     tryTo<int>(str).then([](int i) { use(i); });

 ?

 Would it be sane to add these to std.conv alongside existing 
 std.conv.to so that underlying logic in std.conv.to can be 
 reused?

 If so, AFAICT, existing std.conv.to should be implemented on 
 top of std.conv.tryTo.


Well, for now you can use `ifThrown` from std.exception:

https://dlang.org/phobos/std_exception.html#ifThrown

---
"foo".to!int.ifThrown(42)
---

https://run.dlang.io/is/nlZKOw

Usage of optionals/nullables is sadly not very common in Phobos 
and I think if we want everything to work nicely, we probably 
have to start a new standard library (or do massive refactorings 
of the existing one.)
Aug 15 2018
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 15 August 2018 at 09:26:26 UTC, Seb wrote:

 If so, AFAICT, existing std.conv.to should be implemented on 
 top of std.conv.tryTo.


 Well, for now you can use `ifThrown` from std.exception:

 https://dlang.org/phobos/std_exception.html#ifThrown

 ---
 "foo".to!int.ifThrown(42)


But the whole idea is to avoid both throwing and catching 
exceptions at all. As this results in orders of magnitudes of 
drop in performance for the throwing case. That's the reason why 
Folly has this aswell.

Thanks anyway, Seb.
Aug 15 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, August 15, 2018 3:21:29 AM MDT Per Nordlöw via Digitalmars-d-
learn wrote:

 Have anybody thought about non-throwing variants of std.conv.to
 typically named `tryTo`
 similar to what Folly

 https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throw
 ing-interfaces

 does, for instance, as

      tryTo<int>(str).then([](int i) { use(i); });

 ?

 Would it be sane to add these to std.conv alongside existing
 std.conv.to so that underlying logic in std.conv.to can be reused?

 If so, AFAICT, existing std.conv.to should be implemented on top
 of std.conv.tryTo.


Yes. I've considered writing a set of conversion functions like std.conv.to
which return a Nullable!T (where the target type is T) and return
Nullable!T.init when the conversion fails rather than throwing, and they
really should be in std.conv alongside to, reusing logic as much as
reasonably possible, but it's not a small project. It's come up off and on
for a while now, so I expect that someone will do it eventually (and I may
at some point if no one else does), but obviously, someone has to actually
take the time to do it, or it's not going to happen.

- Jonathan M Davis
Aug 15 2018
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 15 August 2018 at 10:38:23 UTC, Jonathan M Davis 
wrote:

 Would it be sane to add these to std.conv alongside existing 
 std.conv.to so that underlying logic in std.conv.to can be 
 reused?

 If so, AFAICT, existing std.conv.to should be implemented on




Put something together to get early feedback on the idea:

https://github.com/dlang/phobos/pull/6665
Aug 15 2018