-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Request for suggestions: Support negative integers in the slice
filter
#1850
Comments
This seems low-risk since old themes wouldn’t use negatives, right? |
Do not forget that the first arguments accepts negative values: {% liquid
assign fruit_list = 'apple,banana,cherry,tomato,fig' | split: ','
# Similar to | slice: 1, -3
assign sliced_fruit_list = fruit_list | slice: -4, 1
echo sliced_fruit_list | append: '<br>'
# => ["banana"]
%} As it can reasonably be expected that you will calculate either the Nice use-case though, I don't think I ever used the |
Could possibly impact some custom codes, if they treat negative values as {%- liquid
# Count get assigned to -2
assign count = array.size | minus: 5
assign sliced_list = array | slice: 0, count |
RFC 9535 - JSONPath has an excellent description of slice semantics for its "slice selector". As well as negative I thought it would be interesting to see what a Liquid filter following the same rules looked like. In this example I've called the filter (This could be simplified if def range(input, start=nil, stop=nil, step=nil)
input = Utils.to_s(input) unless input.is_a?(Array)
# Working around awkward keyword argument behavior so start, stop and
# step are all optional. :(
if start.is_a?(Hash)
stop = start['stop']
step = start['step']
start = start['start']
elsif stop.is_a?(Hash)
start ||= stop['start']
step ||= stop['step']
stop = stop['stop']
elsif step.is_a?(Hash)
start ||= step['start']
stop ||= step['stop']
step = step['step']
end
step = Utils.to_integer(step || 1)
length = input.length
return [] if length.zero? || step.zero?
start = Utils.to_integer(start) unless start.nil?
stop = Utils.to_integer(stop) unless stop.nil?
normalized_start = if start.nil?
step.negative? ? length - 1 : 0
elsif start&.negative?
[length + start, 0].max
else
[start, length - 1].min
end
normalized_stop = if stop.nil?
step.negative? ? -1 : length
elsif stop&.negative?
[length + stop, -1].max
else
[stop, length].min
end
# This does not work with Ruby 3.1
# input[(normalized_start...normalized_stop).step(step)]
#
# But this does.
(normalized_start...normalized_stop).step(step).map { |i| input[i] }
end Usage examples # frozen_string_literal: true
require "liquid"
source = <<~LIQUID
{% assign a = '0,1,2,3,4,5,6,7,8,9' | split: ',' -%}
{{ a | range: 1, 3 | join: ', '}}
{{ a | range: 1, -3 | join: ', '}}
{{ a | range: 1, 6, 2 | join: ', '}}
{{ a | range: step: 2 | join: ', '}}
{{ a | range: step: -1 | join: ', '}}
{{ a | range: 2, step: -1 | join: ', '}}
{{ a | range: -1, -6, -2 | join: ', '}}
{{ a | range: stop: 0, step: -1 | join: ', '}}
LIQUID
template = Liquid::Template.parse(source, error_mode: :strict)
puts template.render! Output
|
Author: Shopify
Expected end date: December 5, 2024
Background
Today, the
slice
filter is limited to counting items from the start index, with no option to count backwards from the end. This creates unnecessary toil, affecting the developer experience, as seen in the following examples.It's straightforward counting from the index:
However, operations such as getting all array elements except the last two can become verbose:
Proposal
Inspired by
slice
operations in other languages, we propose supporting negative numbers in the second argument, making operations more intuitive by controlling the direction of elements being taken.With this enhancement, that example becomes simpler and clearer:
Here's how the negative number influences the direction of the second argument:
Limitations
This proposal is not currently backward compatible:
Therefore, we will conduct an impact assessment to evaluate the feasibility and ensure a smooth transition if this change is implemented.
Call for suggestions
We welcome any feedback or opinions on this proposal. Please share your thoughts by December 5, 2024. Your input is valuable as we prepare to begin active development on this initiative.
The text was updated successfully, but these errors were encountered: