Issue #14654 has been updated by Jeff McCune. Status changed from Accepted to Duplicate
# Action Required # We have gone back and forth on this a lot. At the very best we're wildly inconsistent in 3.x and all of our values for undef internally evaluate to truth and internally have non-empty to_s implementations. Based on the huge number of undef related tickets in the issue tracker, I'm making a stand and saying #15329 is the real root cause of all of these issues. If you are a watcher on this ticket, please transfer your most pressing concerns to #15329. Here is the list of related "undef" issues that I've found so far: #4692 #5820 #6621 #6745 #8778 #8783 #13210 #14654 #14677 #14666 I am going to close this ticket as a duplicate of #15329. Again, please transfer your most pressing concerns to #15329 in an effort to consolidate all of the issues related to undef variables in the Puppet DSL. Thanks, -Jeff ---------------------------------------- Feature #14654: :undef should not be synonymous with the empty string in Puppet if/case/selector https://projects.puppetlabs.com/issues/14654#change-66235 Author: Reid Vandewiele Status: Duplicate Priority: Normal Assignee: Category: Target version: Waldorf Affected Puppet version: Keywords: Branch: This feature request is a spin-off of the resolution of #8778. In trying to trace back through :undef-related tickets in order to get a better idea of what the intention moving forward is, I unearthed issues #4692, #6621, #6745, #8783, and #13210. Most of those tickets were about exposing the :undef symbol in ruby (custom functions, templates) but in a completely biased fashion I came up with a few quotes that I think are more generally applicable to the use of 'undef' in the Puppet DSL. Paul Berry in #4692: > We’d intended for :undef to only be used internally within Puppet to > distinguish between undefined variables and variables whose values are the > empty string. Matt Robinson in #8783: > Puppet’s concept of undef seems fairly easy to confuse with empty string, > Ruby’s nil, and often gets exposed through the symbol :undef when it > shouldn’t. It doesn’t seem to me like there’s an overall philosophy behind > undef and how it should be treated in Puppet. Chris Price in #13210: > [...] there are cases in the world where there is a meaningful semantic > distinction between “null” and an empty string (plenty of precedent for this > in relational databases, etc.), and [...] our current implementation > explicitly prevents users from handling that distinction. It's because of the latter-most sentiment that code I am familiar with deliberately checks to see if values are undef rather than empty strings (`if $val == undef`), and expects there to be a difference. These checks all break starting with Puppet 2.7.15 as a result of the #8778 resolution. The style guide currently recommends against checking to see if a value is undef, suggesting instead that a picked-from-a-hat 'UNSET' string should be used in class parameter defaults and that DSL code should be written to handle that conventionally defined string rather than using a language-level "null" check. The fact that this used to work (with :undef) was a bug. Fixing the #8778 bug resulted in Puppet more consistently enforcing the inconsistency of :undef in the Puppet DSL. Consider the following example which for 2.7.15rc1 or greater demonstrates a situation in which :undef is already not synonymous with the empty string. notify { "if message is undef, the title will be used instead": message => undef, } if "" == undef { notify { "then this message should not be empty": message => "", } } ## Feature Request ## In order to allow users to account for the meaningful distinction between "null" and an empty string, :undef should not be synonymous with the empty string in Puppet if/case/selector. For if/case/selector checks, it should be that undef == undef, but nothing else. undef != '' and '' != undef. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
