It violates the fundamental principle of least surprise. The code fails in subtle fashion.

The trigger gets fired whenever a value is explicitly set for an attribute, but not when it's implicitly set by a default/builder. Basically, it's triggered by the outside world setting a value, but not triggered by the internal workings of the attribute. The default/builder is itself a coderef though, so can execute arbitrary code, including doing whatever the trigger would do.

I don't think this violates the principle of least surprise if you consider the usual definition of "trigger". A trigger is a device that responds when it is pressed. You press the trigger on an attribute by supplying a value for it. If you don't supply a value for it, then the trigger doesn't get pressed.

In any case, Moose has had this behaviour for triggers since they were introduced in 2006, and changing it would break a lot of stuff.

toby döt ink

Basically, it's triggered by the outside world setting a value

When you said "it's not set if the attribute is set by a default/builder", I thought you meant this didn't call the trigger:

CowTime->new( timestamp => ... )
[download]

I thought of the constructor (called BUILD and BUILDARGS in Moose) when you said "builder", but I now presume you were specifically referring to the builder attribute property.

In any case, Moose has had this behaviour for triggers since they were introduced in 2006, and changing it would break a lot of stuff.

I didn't say anything about changing Moose. I said your code needed to be changed. But that's when I thought passing a value to the constructor didn't call the trigger.