Jira (PUP-8101) Optional[] data type doesn't allow a parameter to be disabled

[Henrik Lindberg (JIRA)]

Title: Message Title

Henrik Lindberg commented on PUP-8101   Re: Optional[] data type doesn't allow a parameter to be disabled guess that I don't really see what the point of Optional is if it's so difficult to make an optional parameter. I don't think that a user should have to jump through hoops to do what seems like a straightforward task. I regret that we named the data type Optional[T}, we should instead have used Undef[T] type since the meaning is "allows an undef value or instance of T" - essentially the same as the longer form Variant[Undef, T]. The name "optional" suggest that there is some kind of "optionality" involved in a particular context, but that is not the case. We did make this worse by allowing Optional around a key in a Struct to make the key optional (so, there we did use it for "optionality"). When used in a struct it you may have something like Optional[key] => Optional[String] which means "key may be missing, if it exists it can be set to undef or a String value". This complexity is needed since you want to be able to restrict a key such that "key may be missing, if set it must be a String value". If we apply the same kind of syntax to a parameter list, we end up with the hideous Optional[String] Optional[$bar] = 'something' (which may be unparseable). In order to truly support optionality for class and resource parameter we need a different marker - akin to the "splat" (for one or more values). Thus, your original case could then be supported like this: class myclass(Array ?$foo = ['a', 'b', 'c']) { ... } The ? would mean "optional" and implies that the given type T is turned into Optional[T] unless undef is already assignable to T (that way you can skip wrapping the T). This syntax would provide the required information that you indeed want to be able to assign an undef value by using the resource expressions - that is, this would work: class { 'myclass': foo => undef } Unfortunately we cannot take a type of a parameter to which you can assign undef to mean that the parameter has "optionality" as that would be backwards incompatible and cause subtle breakage. I really wish I could go back in time and fix this... Add Comment   This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.