Propose: Add support for connection numbering in sequence diagram.

[charleslai2000]

Provide automatic numbering in sequence diagram is useful when diagram is very complex and software design documents need provide details for each flow in sequence diagram.

Please add this feature into sequence diagram. It is not complex but can reduce a lot of work to number and adjust them mannually.

[alixander]

Note:

I think the best way to do this will be to extend vars and implement dynamic values for vars.

vars: {
  counter: enumerate(1) # starts at index 1
}

shape: sequence_diagram
a
b

a -> b: "${counter}: hello world"
a -> b: "${counter}: second message"

[bo-ku-ra]

i think using '$' is confusing because it gets mixed up with other static variables

[alixander]

@bo-ku-ra what do you mean other static variables? can you give an example of where this is confusing?

[bo-ku-ra]

@alixander
${true} and ${false} are static variables.
${counter} and ${counter2} are dynamic variables.
i would understand them if I named them myself, but i would be confusing if someone else named them.
especially with big d2 source files.

vars: {
  counter: enumerate(1) # starts at index 1
  counter2: enumerate(1) # starts at index 1
}

sequence: {
  style.fill: mistyrose
  shape: sequence_diagram

  a
  b

a -> b: "${counter}: hello world"
a -> b: "${counter}: second message"
}

sequence2: {
  style.fill: mistyrose
  shape: sequence_diagram

  a
  b

a -> b: "${counter2}: hello world"
a -> b: "${counter2}: second message"
}

vars: {
  #'vers' does not have to be at the beginning of this source.
  true: 0
  false: 1
}

true -> false -> sequence
true -> sequence2

true: ${true}
false: ${false}

[alixander]

I see what you mean. The alternative is to have it look like a function call explicitly right?

e.g. something like

...
# Clear dynamic and clear static
a -> b: '${counter()}: hello ${name}'

---

I see the benefit, but there is precedent: Ruby is a top programming language worldwide that doesn't make function calls explicit (x = foo can be either setting to a variable or a function call). In a general purpose programming language it's even more important to distinguish.

I personally don't agree with their design choice, but it at least proves that in 10000x larger environments, some of the biggest software has been able to be written with ambiguous variables.

Using dynamic variables in D2 would also be a lot less frequent than calling functions in Ruby.

So

1. The ambiguity in practice seems to not matter much as proven by Ruby
2. Even if it it ambiguous, there will in practice be few cases of it in a D2 program

[bo-ku-ra]

# Clear dynamic and clear static
a -> b: '${counter()}: hello ${name}'

sound good.
this tips should be in the d2 docs.