[PUP-7401] Aliased types are not indistinguishable from the original type Created: 2017/03/28  Updated: 2018/02/05  Resolved: 2017/11/16

Status: Closed
Project: Puppet
Component/s: Language
Affects Version/s: PUP 4.10.9, PUP 5.0.0
Fix Version/s: PUP 4.10.10, PUP 5.3.4, PUP 5.4.0

Type: Bug Priority: Normal
Reporter: Sean Millichamp Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to PUP-8147 An aliased type should inherit the tr... Closed
Epic Link: 5.y Type System
Sub-team: Language
Team: Platform Core
Story Points: 1
Sprint: Platform Core KANBAN
Release Notes: Bug Fix
Release Notes Summary: A type alias to a type that is iterable did not allow the alias to be iterated. This is now fixed.
QA Risk Assessment: No Action


I stumbled across a behavior relating to aliased data types which seems inconsistent with the documentation / specification. Per https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md#type-aliases "An aliased type is indistinguishable from the original type." I believe I have found at least one instance where that is not so.

Example 1:


$a = Enum['a','b']
$a.each |$x| { notice($x) }

$ puppet apply enum.pp 
Notice: Scope(Class[main]): a
Notice: Scope(Class[main]): b
Notice: Compiled catalog for localhost.localdomain in environment production in 0.02 seconds
Notice: Applied catalog in 0.09 seconds

Example 2 (with aliased type):


type Custom = Enum['a','b']
$a = Custom
$a.each |$x| { notice($x) }

$ puppet apply custom.pp 
Error: Evaluation Error: Error while evaluating a Method call, 'each' expects one of:
  (Hash[Any, Any] hash, Callable[2, 2] block)
    rejected: parameter 'hash' expects a Hash value, got Type
  (Hash[Any, Any] hash, Callable[1, 1] block)
    rejected: parameter 'hash' expects a Hash value, got Type
  (Iterable enumerable, Callable[2, 2] block)
    rejected: parameter 'enumerable' expects an Iterable value, got Type
  (Iterable enumerable, Callable[1, 1] block)
    rejected: parameter 'enumerable' expects an Iterable value, got Type at custom.pp:4:3 on node localhost.localdomain

I would have expected that the Iterable behavior would have transitioned with the custom type.

I have seen this behavior on 4.7.0 as well as a current master branch (4.9.4-488-gcef0271).

Thank you.

Comment by Henrik Lindberg [ 2017/03/28 ]

Sean Millichamp Thanks for reporting. You are right, that should work - the check for iterable value needs to resolve the type before checking if it is iterable, now it just gives up on the unresolved type reference.

Comment by Eric Sorenson [ 2017/04/20 ]

Moving this out of 5.0.0 as it is a bugfix that can come in after the initial release.

Comment by Henrik Lindberg [ 2017/11/11 ]

Stumbled on this again - this is annoying. Think we should fix this for 4.10.x. Ping Thomas Hallgren

Comment by Thomas Hallgren [ 2017/11/11 ]

This is per design. When a type mismatch is described for two distinctly different types, those types are not described in detail. Please note the method receiver here is not an instance of an aliased type. It is indeed an instance of Type. If the Type were to be expanded, then the output would show Type[Custom] and not just Custom. The problem is therefore not that an alias is indistinguishable from Type, it's rather that the Type is displayed without a parameter because it's distinctly different from the expected type Hash or Iterable.

There is also another problem. Although the Type[Enum] implements Iterable, the Type[Custom] does not. A TypeAlias should probably inherit such traits from its actual type.

Comment by Thomas Hallgren [ 2017/11/11 ]

I created ticket PUP-8147 to capture the "type alias doesn't inherit the traits of the type that it is an alias for" problem.

Comment by Henrik Lindberg [ 2017/11/11 ]

I thought that is what this ticket is about...

Comment by Thomas Hallgren [ 2017/11/11 ]

Sweet. I missed the double negation in the title. Closing PUP-8147.

The PR currently on this ticket is an improvement in any case since it clarifies what's being acted upon. An additional PR is needed to make the alias iterable when it represents an iterable type.

Comment by Thomas Hallgren [ 2017/11/11 ]

Second PR added.

Comment by Henrik Lindberg [ 2017/11/13 ]

both merged, and also merged up to 5.3 and master

Comment by Melissa Stone [ 2017/11/16 ]

This has passed CI

Generated at Sun Jul 12 23:23:34 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.