`docker stack` subcommands: the `:?` interpolation operator and hyphens do not mix

Description

If a compose file processed by docker stack subcommands (deploy, config) contains an interpolation token of the form ${KEY:?hyphenated - message} then it is misinterpreted as if it were a different valid interpolation token: ${KEY- message}. This seems to be specific to docker stack -- docker compose does not exhibit the same issue.

Reproduce

No swarm or daemon required to demonstrate with docker stack config:

Files

repro-hyphen.yml:

services:
  demo:
    image: busybox
    environment:
      RESULT: ${UNSET_VARIABLE:?must be set - hyphen in this message}

repro-control.yml -- identical but for the hyphen:

services:
  demo:
    image: busybox
    environment:
      RESULT: ${UNSET_VARIABLE:?must be set; no hyphen in this message}

Demo

unset UNSET_VARIABLE

docker stack config -c repro-control.yml   # correctly fails
docker stack config -c repro-hyphen.yml    # incorrectly succeeds
docker compose -f repro-hyphen.yml config  # correctly fails — same file

Expected behavior

docker stack config -c repro-hyphen.yml should fail, emitting a message such as the one docker compose emits:

error while interpolating services.demo.environment.RESULT: required variable UNSET_VARIABLE is missing a value: must be set - hyphen in this message

docker version

Client: Docker Engine - Community
 Version:           29.4.3
 API version:       1.54
 Go version:        go1.26.2
 Git commit:        055a478
 Built:             Wed May  6 17:10:10 2026
 OS/Arch:           linux/arm64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.4.3
  API version:      1.54 (minimum version 1.40)
  Go version:       go1.26.2
  Git commit:       56be731
  Built:            Wed May  6 17:10:10 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.3
  GitCommit:        77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc:
  Version:          1.3.5
  GitCommit:        v1.3.5-0-g488fc13e
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client: Docker Engine - Community
 Version:    29.4.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.33.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 59
  Running: 40
  Paused: 0
  Stopped: 19
 Images: 53
 Server Version: 29.4.3
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: active
  NodeID: cj4qpcbulk1pygy1qv3u8pejt
  Is Manager: true
  ClusterID: ia2ohfodbrxfj4za7k4cdnajl
  Managers: 1
  Nodes: 2
  Default Address Pool: 10.0.0.0/8  
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: <redacted>
  Manager Addresses:
   <redacted>
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc version: v1.3.5-0-g488fc13e
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.17.0-1013-aws
 Operating System: Ubuntu 24.04.4 LTS
 OSType: linux
 Architecture: aarch64
 CPUs: 8
 Total Memory: 30.75GiB
 Name: <redacted>
 ID: <redacted>
 Docker Root Dir: /opt/docker-data
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  registry:5000
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Additional Info

It looks like this is related to the use of the DefaultSubstitutionFuncs array in docker/cli/cli/compose/template/template.go and the behavior of the hardDefault substitution function.

It also looks like this may generalize to a broader class of issues where a default value or error message in an interpolation token contains characters matching a different operator.

Start in docker/cli/cli/compose/template/template.go, especially DefaultSubstitutionFuncs and hardDefault, and reproduce the behavior with the provided repro-hyphen.yml using docker stack config. Compare it with docker compose config and the control file. Done means docker stack config rejects the hyphenated :? message and reports the required-variable error instead of succeeding.