Timeline for Sandbox for Proposed Challenges
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2022 at 20:34 | history | edited | emanresu A | CC BY-SA 4.0 |
deleted 740 characters in body
|
| Jun 12, 2022 at 20:44 | history | edited | emanresu A | CC BY-SA 4.0 |
added 7 characters in body
|
| Jun 12, 2022 at 19:46 | comment | added | emanresu A | @pxeger Added.. | |
| Jun 12, 2022 at 19:45 | history | edited | emanresu A | CC BY-SA 4.0 |
added 12 characters in body
|
| Jun 12, 2022 at 12:22 | comment | added | pxeger |
Suggested falsey test-case: [[]][[]], which may erroneously be accepted by eval-like solutions
|
|
| Jun 12, 2022 at 9:22 | history | edited | emanresu A | CC BY-SA 4.0 |
added 102 characters in body
|
| Jun 12, 2022 at 9:20 | comment | added | pxeger |
[...contd] But I think disallowing error output is not the right way to go about it, because (1) people will still post them, but wrapped in a try-catch or whatever, which is a no more interesting answer; and (2) people can write interesting answers which don't use eval, but which can be shorter using error output as a kind of "short-circuiting" output mechanism.
|
|
| Jun 12, 2022 at 9:19 | comment | added | emanresu A | @pxeger Good idea :P | |
| Jun 12, 2022 at 9:18 | comment | added | pxeger |
"Outputting by erroring/not erroring is not allowed" - I presume this is to prevent people from submitting solutions which are just eval. This tends not be a good approach, and I think solutions like eval are still interesting. Maybe instead you could ask that people post solutions which don't directly do any parsing into one Community Wiki answer, like is sometimes done for builtin answers to catalogue-style questions. [contd...]
|
|
| Jun 12, 2022 at 5:28 | comment | added | pajonk |
Suggestion: allow input also with {} or (), maybe even allow separators to be spaces or semicolons.
|
|
| Jun 12, 2022 at 2:28 | history | answered | emanresu A | CC BY-SA 4.0 |