search

metaeducation / ren-c

Library for embedding a Rebol interpreter into C codebases
GNU Lesser General Public License v3.0
128 stars 27 forks source link

TRANSCODE/NEXT on DATE/TIME returns the wrong position #1109

Closed rgchris closed 3 years ago

rgchris commented 3 years ago

Example:

>> [v p]: transcode/next to binary! "7-Feb-2021/23:00" reduce [v p]
== [7-Feb-2021/23:00 #{2F32333A3030}]

In older versions (inc. R3C and Rebol 3 Alpha):

>> transcode/next to binary! "7-Feb-2021/23:00"                                                 
== [7-Feb-2021/23:00 #{2F32333A3030}]

Expect:

== [7-Feb-2021/23:00 #{}]
hostilefork commented 3 years ago

Patched here: https://github.com/metaeducation/ren-c/commit/26addebcec2207d43f8c991aa146ea2d6e62e2e0

Note that the multiple return concept is that you don't need the /NEXT, it is implicit by using the slot in the multi-return:

>> [v p]: transcode to binary! "7-Feb-2021/23:00"  ; no /NEXT
>> reduce [v p]
== [7-Feb-2021/23:00 #{}]

It actually should error to provide the /NEXT when it's specified by a multi-return. It should only be a refinement if you're passing the argument as a WORD!.

I've thought maybe annotating with a refinement in the returns could be an option if you want to document or double-check:

>> [v /next p]: transcode to binary! "7-Feb-2021/23:00"
>> reduce [v p]
== [7-Feb-2021/23:00 #{}]

You actually wind up taking up more characters that way than:

>> v: transcode/next to binary! "7-Feb-2021/23:00" 'p
>> reduce [v p]
== [7-Feb-2021/23:00 #{}]

But I think it's clearer to see what's going on in the multi-return notation.