Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistent push operator behaviour #215

Closed
gamato opened this issue Dec 2, 2015 · 3 comments
Closed

inconsistent push operator behaviour #215

gamato opened this issue Dec 2, 2015 · 3 comments
Assignees
Milestone

Comments

@gamato
Copy link
Contributor

gamato commented Dec 2, 2015

$ qore -n -e 'list l = (1,2); printf("%n\n", l);'
list: (1, 2)

$ qore -n -e 'list l = (1,2); delete l; printf("%n\n", l);'

$ qore -n -e 'list l = (1,2); delete l; push l, 3; printf("%n\n", l);'
list: (3)

$ qore -n -e 'softlist l = (1,2); delete l; push l, 3; printf("%n\n", l);'

@gamato gamato added the bug label Dec 2, 2015
@davidnich davidnich added this to the 0.8.12 milestone Dec 9, 2015
@tethal
Copy link
Contributor

tethal commented Dec 29, 2015

I assume that for the *list list type this is ok:

$ qore -n -e '*list l = (1, 2); delete l; push l, 3; printf("%n\n", l);'
<NOTHING>

since the default for *list is NOTHING and not an empty list.

However, for the unshift operator we get this:

$ qore -n -e '*list l = (1, 2); delete l; unshift l, 3; printf("%n\n", l);'
unhandled QORE System exception thrown in TID 1 at 2015-12-29 10:05:53.408376 Tue +01:00 (CET) at <command-line>:1
UNSHIFT-ERROR: first argument to unshift is not a list

which is a completely different inconsistency.

@tethal
Copy link
Contributor

tethal commented Dec 29, 2015

After discussion the exception produced by unshift seems reasonable so we will implement this for other list operators as well

@tethal tethal added the fixed label Dec 29, 2015
@tethal tethal closed this as completed Dec 29, 2015
@davidnich davidnich removed the fixed label Jun 2, 2016
@davidnich davidnich reopened this Jun 2, 2016
@davidnich
Copy link
Contributor

in order not to break backward compatibility, the runtime exceptions will only be thrown if %strict-args is in effect

davidnich added a commit that referenced this issue Jun 2, 2016
…pop, push, and shift operators only if %strict-args is in effect in order to preserve backwards-compatibility with code that does not use %strict-args
tethal added a commit that referenced this issue Jun 2, 2016
…ixes

refs #215 throw a runtime exception with lvalue type errors with the …
@tethal tethal added the fixed label Jun 2, 2016
@tethal tethal closed this as completed Jun 2, 2016
tmandys pushed a commit that referenced this issue Jun 2, 2016
…pop, push, and shift operators only if %strict-args is in effect in order to preserve backwards-compatibility with code that does not use %strict-args
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants