15
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Jul 2025
15 points (100.0% liked)
Programming
21903 readers
328 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
First, thanks for the answer. As for the user base, its actually gaming oriented and they typically do not interact with 0 base. So I guess that makes for an obvious choice. And at the moment its also "inclusive". To get one element user needs to
2:2. If user gives only one element, such as2, then I could convert it into2:2, to get one element. Sounds logical, right? Sorry for having so many follow up questions, my head is currently spinning.Do you think this interferes somehow with the logic of a "missing" slice element, which would default to "the rest of the list". In example
2:would then get the second element and until rest. This is the default behavior in Rust.If I have a 1 based index, how would you interpret the
0? Currently program panics at Argument interpretation phase.How much time do you have to program in edge cases? If I had the time and it were me, I'd parse for single number and return a single element. A single number with colon would give the front/back portion of the list accordingly. And two numbers gives the inclusive range.
Then in terms of if you get a zero, swap to zero index mode since they clearly want the start of the list or reject the command explaining the argument isn't zero-based (probably best to reject just for consistency).
The docs/help page will be key here. That and consistency across your app when it comes to zero vs one indexing.
I think that I'm going with these approaches. For the '0', I'm now accepting it as the 0 element. Which is not 0 based index, but it really means before the first element. So any slice with an END of 0 is always nothing. Anything that starts at 0 will basically give you as many elements as END points to.
0:is equivalent to:and1:(meaning everything)0is equivalent to0:0and:0(meaning empty)1:0still empty, because it starts after it ended, which reads like "start by 1, give me 0 elements"1:1gives one element, the first, which reads like "start by 1, give me 1 element"I feel confident about this solution. And thanks for everyone here, this was really what I needed. After trying it out in the test data I have, I personally like this model. This isn't anything surprising, right?
I personally find it easier for non programmers to use a START:LENGTH model.
3:5 is (up to) 5 elements starting at the third.
1:1 is just the first element
Any 0 is invalid
20:2 is elements 20 and 21
It eliminates inclusive/exclusive questions.
Microsoft's print dialog offers custom ranges of pages in an intuitive way, see above
You could demonstrate the numbering system for the users, maybe once at startup. Make it the first thing they see
No, that's not an option here. This is a commandline program, something like
grepin example. And this slice is just one of the many features the user could use to refine the output.I mean to say the numbering system 1, 4, 7-12 to indicate slices of data, not the UI 🤣
other possibilities: 1, 4, 7-rest ("7 through the rest of the slices") or 1, 4, 7... ("7 through the rest of the slices")
and provide it as sample input to the user when they first try to print something, that should give them an idea of how to use your numbering system