Avoid multiple enumeration of array typed path parameters

[Khyalis]

In order to support using array types other than Array for path parameters, Client.Class.PathParameter.liquid uses
System.Linq.Enumerable extension methods, indicating that support is limited to types derived from IEnumerable / IEnumerable<T>.
(Although there may not be explicit guarantees for configured types to implement IEnumerable))

Under these circumstances, the current implementation's for-loop and its use of an index variable may cause some overhead:

• The index variable appears to be mainly used to differentiate between the first and subsequent loop iterations. Otherwise, the intention appears to be to access all collection elements in order.
• The loop condition (including the call into System.Linq.Enumerable.Count()) may be evaluated for every loop iteration, possibly causing multiple enumerations.
• Accessing the "Current" element using System.Linq.ElementAt() may also need to iterate over all previous Elements.

(It might also lead to issues if the System.Linq namespace is not included in usings.)

One idea might be using a foreach-loop, which would also work with IEnumerable (1).

• This would also serve to access all collection elements in order
• It would only need to iterate over the collection once.

E.g.

{
    bool isAfterFirst = false;
    foreach (var item in {{ parameter.VariableName }})
    {
        if (isAfterFirst) urlBuilder_.Append(',');
        urlBuilder_.Append(ConvertToString(item, System.Globalization.CultureInfo.InvariantCulture));
        isAfterFirst = true;
   }
}

As, depending on whether the parameter is optional, the template may be used outside an isolated block,
this declares an nested block in order to avoid name conflicts.
Always ensuring a block in Client.Class.liquid might also work.

As the code generation assumes the configured array type to be generic. Therefore it would also be possible to use a using block with IEnumerator<T>, as, other than IEnumerable, IEnumerable<T> inherits IDisposable (2).
That way, the implementation could avoid a variable for appending the separator.

using (var enumerator = {{ parameter.VariableName }}.GetEnumerator())
{
    if (enumerator.MoveNext())
    {
        urlBuilder_.Append(ConvertToString(enumerator.Current, System.Globalization.CultureInfo.InvariantCulture));

        while (enumerator.MoveNext())
        {
            urlBuilder_.Append(',');
            urlBuilder_.Append(ConvertToString(enumerator.Current, System.Globalization.CultureInfo.InvariantCulture));
        }
    }
}

Picking up the approach of always adding the separator and removing it once in the end for non-empty collections used in other locations might also work (3):

using (var enumerator = {{ parameter.VariableName }}.GetEnumerator())
{
    if (enumerator.MoveNext())
    {
        do
        {
            urlBuilder_.Append(ConvertToString(enumerator.Current, System.Globalization.CultureInfo.InvariantCulture));
            urlBuilder_.Append(',');
        }
        while (enumerator.MoveNext());
        urlBuilder_.Length--;
    }
}

As I'm unsure, which approach might best match the project style, I have included commits for all three variants.

[lahma]

I might be wrong here, but wouldn't the foreach approach be the most idiomatic, easy to read and also would allow some compiler optimization opportunities?

[Khyalis]

I agree.
The possible lack of compiler optimizations and decreased readability would be the downside of working with the IEnumerator directly instead of using foreach.
And the number of iterations can be expected to be reasonably low, so potential benefits of avoiding the checks likely wouldn't manifest.

I will remove the commits that would change the loop from foreach to do while.

[lahma]

Looking good, thank you!